Skip to main content

From Idea to Project

This post is about the "intrauterine" phase of project development, about that ambiguous period between the inception of an idea and the birth of a project.

It is easy to overlook the importance of early project framing because problems tend to be more noticeable during project delivery and post-go-live. However, the difference between hugely successful projects and disappointments is determined by early framing. I will show you tools to improve how you frame opportunities into projects.

Project management (PM) methodologies are similar to the Big Bang cosmology of the universe. In the Big Bang model we can roll back time up to the very first picosecond, but lack an understanding of what (and why) was before. Similarly, in PM methodologies we can roll back time to when the charter was issued by the sponsor, but lack clarity about what happened before. PM methodologies have much to say about planning scope, resources, schedule, risk, procurement, etc. but they are vague about the pre-project period. How did we come to define the project? Why are we choosing this project, why not another? Why is the scope defined the way it is?

It is not that we don't know the right answers, it is just that we don't ask the right questions.
quote Tony Robbins

Predestined to succeed/fail

Framing projects well is crucial. Let me illustrate this with the following chart.

Value created [$$$]FramingProject DeliveryTimeValue erosion, i.e. poorly executed projectValue erosionProject CharterDoing the project RIGHTPoorly framedWell framedDoing the RIGHT projectThe value created by a project depends more on how it was framed than how it is delivered

The green and blue lines are two versions of the "same" project.

In one case (green line) the business opportunity was framed well. You have a precise understanding of the situation you will address with the project and you know how your solution will drive bottom-line value. As an example, imagine that customer satisfaction is decreasing. In the customer survey, the score has dropped from an average of nine out of ten to around six. People are complaining about long wait times in the call center. To address the drop in customer satisfaction, after careful analysis of the situation you have decided to implement a new call center software to facilitate call routing and to improve performance transparency through indepth reporting.

In the other case (blue line) you only have a superficial understanding of the business problem and consequently only a vague understanding of how value will be created. Continuing on the previous example, imagine the alternative scenario in which the call center manager attended a conference where he saw a presentation by a software company and got excited about their call center product. He wants to implement this product because the case study at the conference was very compelling.

By the time the project manager arrives on the scene, the fundamentals of the project have already been decided. Yes, project discipline and a strong project manager will ensure the project is delivered well. It is delivered on time, on budget, on scope, and meeting all the original requirements defined in the charter. However, even if there are issues during project delivery and there is value erosion compared to the original business case such as late delivery or cost overruns, the value created by a well-framed project will far exceed that of a poorly framed project. This is true, even if the project manager on the poorly framed project was Superman himself.

Photo by cottonbro from Pexels

Situation statement

I always start the framing process by crafting a situation statement and a core question. I don't move forward to requirements, planning, estimation, etc. until the project sponsor confirms these.

There is always an urge to get on with the project, or worst, sponsors often have a well-established idea about the (only possible) solution, well before they were able to clearly articulate the situation they want to address. It is especially difficult to convince people to step back and think about the issue instead of jumping right into solution delivery.

The situation statement should be short, not much longer than a tweet. It should provide the description of the as-is situation, state the problem the situation causes, including (typically negative) business consequences that follow. I use the following simple formula to craft this statement.

Problem + Tangible Effect + Consequences

Playing with the call center example above, the situation statement may be expressed in the following way:
The customer satisfaction survey score shows a decreasing trend dropping from a previous average of 9 to a current value of 6. Many of our customers complain about exceedingly long wait times in the call center. As a consequence, we have seen an increase in call abandonment rate up at 5% from a previous 2%, and a drop in average customer revenue down from $100/customer/month to $90/customer/month.

Once the situation statement is ready, we can move onto the focus question. Ideally, this question should address the problem phrased from the Owner's perspective and should define the success criteria, and identify the key stakeholders.

In a context where there is increasing pressure on workforce efficiency, and customer demand for instantaneous service is increasing, what actions can the Head of Sales and Marketing take, that would restore customer satisfaction to 9, and increase the average customer revenue to $120/customer/month?

Initial options analysis

You should always develop a minimum of two solution options. The option the requestor had in mind originally and the option of doing nothing. Of course, this is the minimum, during framing the objective is to define as many viable options as possible. Options should offer a healthy mix of technology and zero-tech solutions. By zero-tech I mean process change, training, engagement, and other "soft" changes that can be implemented without substantial investment into technology.

You may think that doing nothing is seldom the right option. The requestor has gone through the trouble of developing a situation statement and a core question, surely we should not stop here. However, in my experience, the effort of delivering a project is always seriously underestimated. No doubt, if you could magically make things happen, every project would be financially viable. Considering however the cost and effort of change, and the opportunity cost of not doing other projects, complex solutions that drive only marginal improvements are seldom viable.

Here are couple of options that I would explore regarding the customer satisfaction and revenue issue.

  • Do nothing.
  • Increase call center staffing.
  • Implement a new call center application that will improve call routing, and offer automated service fulfillment and customer call prioritization.
  • Upgrade current call center system and/or re-train call center staff to improve system usage.
  • Implement a web/mobile/chatbot solution for palcing and tracking orders (or whatever the most frequent customer need is).
  • Outsource call center services to a telesales provider.

Interestingly, our original idea in the section above, for implementing a new call center application may not be the best alternative. Maybe we should rather consider moving the ordering and tracking process online or we should fine-tune the existing system and re-train staff.

Now imagine the call center manager who went to the conference and saw that fancy presentation about some new technology. Without understanding or assessing any of these options, he might be jumping into an expensive solution involving a long project, when all that needs to be done is some training and fine-tuning of the existing system.

Root cause analysis

As you were thinking about the options above hopefully you realized that without a deeper understanding of the root cause, it is impossible to identify the right solution. Each of the solutions may be right, depending on your situation. This is why root cause analysis is essential before even deciding to initiate the project. There are many approaches to root cause analysis. I will briefly mention two of the most popular ones.

Five whys

The five whys method is very simple. When you face a problem you can drill down to its root cause by asking "Why?" five times. The technique was originally developed by Sakichi Toyoda and was used within Toyota Motor Corporation. Nowadays, five whys is a basic root cause analysis approach in Kaizen, lean manufacturing, and Six Sigma.

Here's a sample five whys assessment for our problem. Looking at the result of this analysis, it seems that none of the options we have defined earlier would lead to a breakthrough. It now seems that the root cause is not within the call center organization, but elsewhere in the process.

Customer satisfaction and theaverage revenue per customer is droppingProblem:Why?Long wait times on callsWhy?Orders recorded slowlyWhy?Credit check takes agesWhy?Policy does not include value limit for credit checkWhy?Everyone customer goes through full check each time


The fishbone diagram (a.k.a. Ishikawa diagram) is a cause-and-effect diagram defining the underlying reasons for the problems experienced. It was created by Kaoru Ishikawa in the 1960s. Causes are grouped into categories. Some of the popular set of categories are the 5Ms used in manufacturing (Man, Machine, Material, Method, Measurement), the 8 Ps used in product marketing (Product, Price, Place, Promotion, People, Process, Physical evidence, Performance), and the 4Ss used in service industries (Surroundings, Suppliers, Systems, Skill). You can freely craft your own categories as well.

Doing the fishbone for the customer satisfaction and revenue problem reveals some low hanging fruit opportunites that management could implement without needing a project. While these may not fully resolve the issue for the customer, they will nodoubt result in some level of improvement

Customersatisfaction andthe average revenue per customer is droppingPeopleProcessSystemsManagementEnvironmentcredit checkCustomers expectfast responsestaff-count lowdue to efficiencytargetsDon't understandcredit check proc.Callcenter appis datedNo online orderingplatformType slowlyNo proc. forauto re-orderCall Center ismeasured on efficiencynot profitability

Further reading

Like this post?
Show your support.


Popular posts from this blog

Showcasing Excalidraw

Conor ( @Conaw ) pointed me to Excalidraw last week, and I was blown away by the tool and especially about the opportunities it opens up for  Roam Research ! It is a full-featured, embeddable sketching component ready for web integration. This post will showcase key Excalidraw features and discusses some of the issues I still need to solve to complete its integration into Roam. I spent most of my free time during the week integrating Excalidraw into Roam. This article will introduce Excalidraw by showcasing its features.

Mind mapping with Excalidraw in Obsidian

Mind-mapping is a powerful tool. In this post I will show you how and when I mindmap with Excalidraw in Obsidian and why mindmapping is such a good tool for Personal Knowledge Management. Like this post? Show your support.

Evergreen Note on Note-taking Strategies and Their Practical Implementations

This is an evergreen note that I will be revisit regularly to develop a comprehensive list of note-taking approaches including their practical implementations in various software tools. This post will serve as an elaborate table of contents, including a brief introductory discussion on the importance of note-taking, followed by a high-level walkthrough of each method. Links to posts and videos with detailed examples and descriptions will follow over the coming weeks and months.

Deep Dive Into Roam's Data Structure - Why Roam is Much More Than a Note Taking App

Which are the longest paragraphs in your graph? Which pages did you edit or create last week? How many paragraphs of text do you have in your database in total? Which pages do you have under a given namesapece (e.g. meetings/)?