Project Initiation
The project initiation stage
- The project initiation stage is situated at the very start of the project management life cycle. This is the stage that precedes the actual start of the project.
- The main goal of the initiation stage is to reduce the amount of uncertainty to an appropriate level to make a final decision whether to approve the project or not. We need to consider two types of risk:
- Business Risk: Will the outcome of the project actually create the envisioned value? This kind of risk does not really belong to the field of project management, but rather to the domain of product development. Nevertheless, it is during the initiation stage that this risk needs to be assessed and reduced to acceptable levels.
- Project Risk: Will the project deliver the promised outcome within budget and on time? Management of this risk is an essential part of project management. The goal of the initiation stage is to provide a first estimated answer to this question. It is important to realize that this answer is based on estimates with varying accuracy.
- How much of the uncertainty (in terms of risk and estimates) needs to be reduced during the initiation stage is a trade-off between the minimum amount of certainty to make a project approval decision required and the maximum amount of time and resources spent during this stage.
- As will become clear, this project management stage is closely related to the Ideation and Design stage of the product development life cycle. The more uncertainty needs to be removed, the more detailed the design needs to become and the more effort must be put into the project initiation stage. At a certain point, this can become so extensive that the initiation stage (and thus the ideation and design stage of the product development life cycle) becomes a project on its own.
- At the same time, there is an inherent risk of spending too much time on this stage. Particularly in an environment that changes rapidly or where customer needs are not stable, spending too much time and effort on the initiation stage can lead to a project with low project risk, but high business risk (as by the time the project starts, what will be developed no longer matches what the customer needs).
- The start of this stage can sometimes be very clear, but often it is not.
- In case of an urgent problem that needs attention, a clear precise directive can be given to initiate a project which should solve the problem. In such a case, the start of the initiation stage is well-defined.
- Often the idea for a project grows slowly inside the heads of a few people, who at a certain point in time decide to follow a more structured approach and transition to a more formal initiation stage.
- The project initiation stage consists of:
- Analysis of the problem/opportunity under consideration
- Development of a project proposal
- Stakeholder analysis
- Definition of the project rules
- Evaluation of the project proposal
Problem Analysis
- The project initiation stage typically starts off with a first informal analysis of the problem/opportunity the project tries to tackle. Note that ideally the project initiation stage starts from a problem or opportunity for which a solution or application is searched, rather than directly from a predefined solution or application.
- It is important to realize that the purpose of a project is to solve a problem or exploit an opportunity. Failing to clarify the problem/opportunity is therefore a common source of disappointment, particularly because it is routinely discovered after the project is completed.
- Therefore, it is important to define the problem/opportunity in a clear way. One way to do this, is by articulating the problem as the gap between the as-is state and the ideal state. This approach is also known as gap-analysis.
- One should always try to define the to-be state in terms of what the customer is going to be able to do as a result of the project (when successful).
- This should result in carefully written descriptions of what the deliverable must be able to do. We call these descriptions the requirements.
- Note that requirements only define what the deliverable must do, not how it should be done! Requirements are a first direct translation of the problem to the deliverable. Any deliverable that doesn’t meet the requirements, are not capable of solving the problem or exploiting the opportunity.
- Requirements should be written down in such a way that it is easy to recognize whether they are met or not.
- To identify and define requirements, the most important perspective is that of the customer.
- Therefore it is important to understand who the customers are, which problems they experience and which needs they have.
- Remember that customers are often not very good at making their needs explicit. Do not mistake what a customer wants with what they need. Specific methods to discover customer needs are focus groups, surveys, site visits, usability studies and market research.
- This perspective is closely related to the desirability criterium of project value.
- Common ways to express these requirements are through use cases of user stories.
- As projects and their deliverables are not islands on their own, other requirements can relate to the organizational structure, strategy and existing technological constraints. It makes sense that the project outcome should fit within the organizational strategy and the existing technological architecture.
- Once the problem/opportunity is clearly analysed and root causes are identified, creativity is needed to design potential solutions.
- This is where the design of the solution starts and the requirements (what) are translated into specifications (how).
- This typically consists of a divergent and subsequent convergent phase.
- The divergent phase is where you should invest in creativity and exploration. This is the stage where the least amount of money has been spent and the greatest number of options exist. The cost of exploring a new idea can be small and often only requires a limited amount of time.
- This creativity finds its inspiration in understanding the stakeholders and their needs. It is important to realize that while searching for a solution that meets the requirements a substantial set of constraints are defined (explicitly and implicitly). Creativity requires knowledge which constraints can be ignored and when. Thus requires a strong understanding of the stakeholders.
- During the convergent phase, one should try to quantify the costs and benefits of each proposed solution. During this stage, you should expose the ideas to criticism and invite others to evaluate the ideas honestly on the three main criteria: viability, desirability and feasibility.
- To be effective, there must be a interaction between defining requirements and creating specifications. If during the specification development stage it appears that certain requirements can’t be met, the requirements should be re-evaluated. Therefore, it is often most efficient when the members designing the solution also have the authority to change the requirements where necessary.
Stakeholder Analysis
- Involving stakeholders in the project initiation stage is very important but also relatively difficult.
- It is very important as this is the stage where the goals and direction of the project are determined.
- It is relatively difficult during this stage as the group of potential stakeholders is still very broad which makes it more complex to correctly analyse the problem and propose a solution.
- Identifying stakeholders should be one of the first tasks (typically done by the project manager) because all the important decisions during the definition and planning stage are made by these stakeholders.
- During the definition stage, it might not be necessary to actively communicate with all stakeholders, but the more stakeholders you identify, the better the assumptions will be about how the project will be perceived.
- Stakeholders can be involved in following activities:
- Establish agreements on the goals and constraints.
- Construct strategies and schedules.
- Approve the budget.
- Ultimately judge the success of the project.
- Stakeholders can be broadly split into two categories: those who are engaged in the project and those who are only affected by the project. Each category can be further divided in stereotypical roles.
Typical roles of engaged stakeholders
- The project manager
- Obviously, this is the person who has to manage the project and make sure the project delivers what is required on time and within budget.
- Once the project manager is identified, it is important to clearly define his or her authority, to whom he/she has to report and their own expectations.
- The project team
- These are the people who are actually going to do the work and this should be considered in the broadest sense.
- People who contribute time, skills and effort to the project.
- Please note that contractors, vendors and even customers can also be part of the project team. Don’t limit yourself to people within the organization.
- Managing these stakeholders typically involves making sure all team members agree to their responsibilities and roles in the project. Obviously, this requires that one first knows who is involved and which work needs to be done by whom.
- Management
- By management, we refer to the typical functional management found within the organization.
- These managers can play two important roles for the project, i.e. as a project sponsor or resource manager.
- The project sponsor is the person with real authority within the organization and provides this authority to the project manager, who typically lacks real authority.
- Project sponsors typically:
- Publish the project charter announcing the existence, purpose and project manager of the project.
- Approve the statement of work.
- Approve the project plan.
- advise the project manager.
- Assists in overcoming organizational hurdles.
- Management also serves the role of resource managers.
- As most members of the project team are often part of a functional department within the organization, they need to be freed from their daily work in order to work on the project.
- Their functional managers act as resource managers to the project.
- These resource managers need to approve on the work that their people assigned to the project will be doing.
- The customer
- The customer is the person who is typically paying for the project and therefore has final control over the requirements, budget and time constraint.
- Therefore, one way to identify customers is by asking who should be involved in making the necessary trade-offs within the iron triangle.
- Notice that it is not uncommon to divide customers into two separate roles: those who define the requirements and those who provide the funding. It is not necessary that these two roles reside with the same person.
- While the engaged stakeholders are often easy to identify and will always stay on the radar, it is not uncommon to oversee or lose track of the stakeholders that are affected but not directly engaged.
- One tactic could be to make stakeholder identification a repeatable activity throughout the project.
- Another tactic could be to actively engage the people who will have to change their behaviour as a result of the project by alerting them about the coming change to win their cooperation. These tactics belong to the field of change management.
Stakeholder Management
- The general process of stakeholder management consist of three stages:
- Identification of stakeholders
- To identify engaged stakeholders you should ask the question: “Who will make a contribution to the project?”
- To identify the affected stakeholders, ask “Who will (have to) change their behaviour by the outcome of the project?”
- Prioritization of stakeholders
- Analysis of stakeholders
Project Proposal
- To determine if a project should get funded and started or not, the main question to be answered is: “How will the project deliver value?”
- Therefore, one of the main deliverables of the initiation stage is a project proposal which tries to answer this question and acts as the basis for evaluating the project.
- A project proposal articulates the benefits of the project in contrast to the costs that need be made. The proposal must convince the reader of the project’s value, which can be judged on following 3 criteria:
- Desirability: The outcome of the project is something the stakeholders want. (Customer perspective)
- Viability: The lifetime cost of the project and its outcome are outweighed by the benefits. (Business perspective)
- Feasibility: The proposed solution by the project is (technically) feasible to realize. (Technological perspective)
- Additionally, a good project proposal also identifies how one can determine during the project if the project is going to achieve its goals or not. However this can be challenging, because the proposed value of the project is often to a great extent realized only when the project has been completed.
- Waiting until the end of the project (and later) to determine if one is on the right track is clearly not acceptable. Therefore, it is important to think about good leading metrics which give an indication whether the project will produce the desired value.
- A leading metric is typically related to a root cause of the problem.
- A proposal should clearly identify what will be measured, when and how.
Project Proposal Template
- Project goal:
- Which are the specific desired results from the project over a specified time period.
- Focus on the value that should be experienced after the project.
- Problem/Opportunity definition.
- Describe the problem/opportunity without suggesting a solution.
- Provide factual evidence of the problem and try to avoid assumptions.
- Describe the problem/opportunity in its context and how it affects the context.
- Proposed solution.
- How will the project address the problem/opportunity.
- Be as specific as possible about the boundaries of the solution.
- Project selection and ranking criteria.
- Ideally, these are already defined as part of project portfolio management.
- Some criteria will focus on the benefits: compliance/regulatory criteria, efficiency/cost reduction criteria, increased revenue criteria, …
- Some criteria will focus on the strategic fit with the organization and other projects.
- Some criteria will focus on the project’s urgency.
- Cost-benefit analysis.
- This part focusses on the financial reasons and represents the results of an quantitative analysis.
- It should focus on 4 elements: tangible benefits, intangible benefits, required resources (cost) and financial return.
- Business requirements.
- Which are the requirements that must be fulfilled in order for the project to have a chance of being successful.
- Scope.
- Describe the major accomplishments the project tries to realize.
- Obstacles and Risks.
- Schedule Overview.
- Describe at a high level the expected duration of the project, the significant milestones and the major phases.
Project Rules
- Properly setting the project rules before the project starts is an important step to prevent difficult discussions during the project execution stage.
- Clear project rules have a positive impact on three project success criteria: goal agreement, project scope control, management support.
- Clear project rules make sure all stakeholders agree up front on the goals of the project and expectations are properly managed.
- Clear project rules makes it explicit who, when and how the scope of the project can (be) changed.
- Clear project rules ensures that the project managers gets the appropriate authority from management to properly manage the project.
- The project rules are typically written down in three different documents:
- The project charter.
- The statement of work.
- The responsibility matrix.
The Project Charter
- The project charter contains:
- The name and purpose of the project.
- The name of the project manager.
- A statement of support from the project sponsor.
- The project charter announces that a new project begins and makes it clear to everybody involved and affected by the project that the project and project manager are supported by the organization’s management level.
- The project charter can be something as simple as a short email from the sponsor to the entire organization.
Statement of Work
- The SOW lists the goals, constraints and success criteria for the project. It can consist of following elements:
- Purpose Statement
- What will be done in the project and why?
- Having a clear purpose statement helps making decisions later on in the project.
- Note that it is not the purpose of the purpose statement (nor the SOW) to develop a business case which justifies the funding of the project. The latter is typically part of the project proposal.
- Scope Statement
- A description of the major activities of the project.
- The scope statement should make it clear at the end of the project which activities were originally part of the project and which were added afterwards.
- It can also be helpful to also define which activities/results are out of scope.
- Be aware of the difference between the project and product scope!
- Product scope describes the features and performance levels of the product/service that is to be created.
- Project scope describes the work and responsibilities of the project.
- Deliverables
- What is the project supposed to produce?
- When appropriate, make a distinction between intermediate and final deliverables.
- When appropriate, make a reference to more detailed product descriptions, typically found in design documents.
- Cost and Schedule Estimates
- The budget and the deadline of the project should be mentioned.
- But also the rules if, how and when the budget and deadline can be changed.
- Measures of Success
- Make it clear how it will be decided whether the project is complete and successful.
- These measures should follow the SMART principles, otherwise it will be difficult to reach agreement up front or, even worse, agreement at the end of the project.
- Stakeholders
- The SOW should clearly identify all stakeholders within the project.
- It is a good idea to write a first draft of the SOW and use this to manage expectations and create agreement among all stakeholders. Based on all the input, one can then rewrite the draft into the final ‘original SOW’
- Note that the SOW can change throughout the project as long as there is agreement and consent among all stakeholders.
Responsibility Matrix
- The responsibility matrix, is also known as a RACI (responsible, accountable, consulted, informed) chart. It details who or which roles hold which responsibilities throughout the project.
- One dimension of this matrix defines the major activities in the project.
- The second dimension defines the different roles/stakeholder groups.
- The cells of the matrix hold any of four possible codes:
- R for ‘responsible’. This person/group is responsible that the work gets done. They have to report to the person who is accountable for the activity.
- A for ‘accountable’. This person/group has the final word on decisions and has to give the final approval whether the work is completed. There should only be 1 person/group responsible.
- C for ‘consulted’. This person/group must be consulted while the activity is done. They can influence the direction and outcome of the activity.
- I for ‘informed’. This person/group must be informed about the decisions, progress and outcome of the activity. They don’t influence the activity.
Project Evaluation
- Because resources are typically limited, launching a new project should be a well considered decision which is made in the context of other running projects, other project opportunities and the overarching organization’s strategy.
- Despite the informal start of the initiation, a more structural and rigorous approach is recommended to determine whether the project should be launched or cancelled.
- A key element is the presence of clear and unambiguous criteria for approving a project.
- When the decision is not only whether a project is worth the effort or not, but rather which of the worthy projects should get the limited budget, an even more structural approach is needed. This approach is known by the term of ‘project portfolio management’ and operates at a higher level than project management.