Project Foundations Series – Part 1. Discovery/Initiation Phase

By Wayne Rambow, Senior Program/Portfolio Delivery Consultant

While the phases of a project are broadly followed, the level of understanding of these phases, the artifacts created, and the levels of governance and controls applied vary dramatically. This series of articles is intended to clarify and simplify the delivery process. I have a lot of experience with PMOs and delivery teams that have taken simple concepts and made them much more complicated than they need to be. Over time, things are added into the process, but nothing is ever removed, until the process collapses under its own weight. As with most things, the simplest solution is the best solution.

This is Part 1 of a 5 Part series discussing Initiation/Discovery, Planning, Execution, Monitoring/Controlling, and finally Closure. I will discuss common deliverables at each phase as well as provide strategies to avoid common pitfalls.

1. What is the Discovery Phase?

The Discovery Phase is a critical stage that sets the foundation for a successful project. At its core, it involves gathering information, understanding requirements, and defining the project's scope.

2. Key Objectives of the Discovery Phase

• Understanding the Problem: Thoroughly understanding the problem or need is crucial before considering solutions. What issues are stakeholders facing? What triggered the need for this project?

• Defining the Project Vision: To achieve the desired results, we must consider the broader picture and the desired outcomes from the perspective of stakeholders. I personally consider this one of the most important parts of the project. A vision, in later phases, helps focus the delivery team on the outcomes of the project. It also aids in the communication plan, elevator pitches, and any other short-form context used during delivery. Understanding the Problem and Defining the Vision defines the “Why” of the project.
• Gathering Requirements: This involves determining the specific needs and requirements of the stakeholders. These requirements can be functional (what the project should do) or non-functional (how the project should do it). This is where your product owners, business analysts, and solution architects, need to come together and document the “What” of a project. Many times, a PM isn’t assigned at this stage, but the coordination taking place at this stage, the discussions, and the decisions being made can be incredibly beneficial to delivery later. This is why I’m a big fan of having PMs assigned to projects even at the discovery phase.
• Risk Assessment: Early identification of potential project pitfalls can pave the way for risk mitigation strategies. The risks at this stage are typically higher-level ones as the solution is still being defined. It’s important to incorporate regular risk reviews throughout the lifecycle of the project to continually evaluate the ever-evolving risk profiles of projects.

3. Tools and Techniques

• Interviews: Conducting one-on-one discussions with stakeholders to gain deep insights. This isn’t just the sponsor, it’s the stakeholders. So, this is subject matter experts, users, impacted parties, etc. This is about understanding the current state, historical issues, lessons learned from similar projects, and desired end state. You want to be curious and be aware that these first interactions foster relationships that will be leveraged later in the project. Hint: If you don’t know who your stakeholders are, spend some time doing stakeholder analysis first. This is the “Who”.
• Surveys and Questionnaires: If you have a broader audience, consider doing some preliminary surveys or questionnaires that can serve as a baseline. It helps you understand the current state and gives you a benchmark, if designed correctly, that you can measure against as you transfer to operations. Hint: Keep this light – going out and asking 100 questions is not going to give you what you are looking for. Common theme, keep it simple, but thoughtful and informative.
• Workshops: Engaging a group in structured activities to brainstorm, prioritize needs, and get consensus. At a minimum, you will get a high-level plan, and if the team has enough information, you could build a comprehensive plan. This is the “When”. I once built a project plan for a large website for one of Canada’s biggest retailers using a boardroom and a bunch of large sticky notes. We planned together from start to finish and although there were changes throughout, this plan was very complete. The project involved over 50 people and took 18 months, but in one morning, with 6-8 SMEs, we had it pretty much mapped out.

?

The ability to facilitate productive workshops is a key tool in a PM’s toolbox. If you haven’t had a chance to do many of these, try to volunteer to help with workshops that are being done so you get a chance to develop these skills.

• Preliminary Solutions & Options: While it is quite likely we do not have the solution fully vetted and understood, the requirements-gathering process should provide at minimum a general direction or options to be considered. Even if the outcome is a solution approach, we start to form the basis of the “How” of the project.

4. Key Deliverables

You’ve invested a lot of time and effort to get to this point, but through discovery, you have a pretty good idea of the 5W’s – Who, What, Where, When, Why, and How – Add some budget estimation and you are likely sitting at a +/- 30% estimate that will refine through the planning process. So, what do you do with all this information? It’s time to start producing some project artifacts.

At this stage, decisions will need to be made; Do we just do a business case and wait for approval to proceed before advancing to planning? Do we just build a Project Charter? Do we do both and if so what’s the difference between them?? Before we can answer that, we need to first define what a Business Case and Project Charter are, and what are the contents of each. Understanding that will help you decide what is the most appropriate for your project.

Business Case

• Definition: The Business Case is a document that outlines the justification for initiating a project. It serves as the basis for decision-making regarding the commitment of resources and is usually prepared before the project is officially started. The Business Case provides stakeholders with the information needed to decide whether the project is worth the investment and aligns with organizational strategy. It’s a key component in gaining approval or funding for the project.

?

Contents:

• Objective: Why the project is necessary.
• Options Appraisal: If multiple approaches are available that would achieve the project’s objectives, options are evaluated along with a recommended option.
• Cost-Benefit Analysis: Evaluation of the financial and non-financial costs and benefits.
• Risk Assessment: Identifying potential risks and uncertainties associated with the project.
• Funding Requirements: Details about the necessary financial investments.
• Return on Investment (ROI): Projections of the financial gains in relation to the investment made if applicable.?

Project Charter (output of Discovery or early in Planning after Project Approval)

Definition: The Project Charter is a formal document that gives official authorization to start the project and provides a brief overview of the project's objectives, scope, stakeholders, and assigned project manager. The Charter acts as a reference throughout the project, giving direction and clarification on project objectives and deliverables. It also gives the project manager the authority to allocate organizational resources to project activities.

Contents:

• Project Purpose or Justification: Why is the project being done (problem statement)?
• Measurable Project Objectives and Requirements: What are the expected outcomes based on the requirements?
• Milestone Plan: When can we expect key deliverables? This gets refined during the planning phase, but these are the best estimates of timing from the team.
• Approach: How the team intends to solve the problem statement and what is the recommended approach?
• High-Level Scope and Out of Scope: Overview of what is included and excluded in the project.
• Overall Project Risk: Key risks identified in the initial phase.
• Project Manager Assigned: Identification of the project manager

Comparison Summary - Business Case & Project Charter

Timing: A Business Case is generally developed before the Project Charter as it helps in the decision-making process of whether to proceed with the project or not.

Focus: A Business Case is more focused on the economic feasibility and justification for the project, including various options and approaches to achieving the project's goals. The Project Charter, on the other hand, is focused on the direction, scope, and success definition once the decision to proceed with the project has been made.

Audience: The Business Case is created primarily for senior management and project sponsors to determine whether to fund the project or not. The Project Charter is designed for a broader audience, including project team members, stakeholders, and anyone else involved in the project, to comprehend the project's direction and initial framework.

A Business Case and/or Project Charter are meant to be the guiding artifacts of a project. They should be short, concise, and informative. I have personally written a 40+ page business case, but that was a full cost analysis on whether an organization should build a data center or outsource. Most of these documents should be 5-6 pages. Your approving audience is usually the Senior Leadership Team (SLT), and they have no interest in reading a massive document. If you cannot convey the value of the project in a few pages, you have a problem. PMOs with starting templates that are 30-40 pages without content beware, when the process adds no value, the process is removed.

Stakeholder Analysis

Stakeholder Analysis plays a vital role in several project management and business processes. It involves identifying and examining the individuals or groups who have a vested interest in a project or decision, and evaluating how they could be impacted by it or how they could affect it. Depending on the complexity, impact, and anticipated amount of Organizational Change Management required for the project, your analysis may be as simple as a contact list, or it may require more depth. Keep it as simple as you can.

?

Contents:

• Stakeholder Register: A document that lists all identified stakeholders along with their relevant information, such as contact details, role in the project, and influence level.
• Communication Strategy: Decide how, when, and what to communicate to each stakeholder group. Tailor your communication strategies based on their needs and influence.
• Personas: Develop stories or personas around who will be using the product or service. This is an exercise about “walking a mile in someone else’s shoes” whereby we understand, from the perspective of others, the most important aspects of the project.

Business Requirements Document

A Business Requirements Document (BRD) is a fundamental document that captures the business needs of a project or product. It serves as a connection between non-technical stakeholders, such as clients or business teams, and the technical teams responsible for building the solution. The BRD emphasizes 'what' is required from a business standpoint, rather than 'how' the solution will be implemented, which is usually outlined in more technical requirement documents or specifications. When creating a BRD, it is crucial to maintain clarity, avoid overly technical jargon, and ensure that all stakeholders, regardless of their technical expertise, can understand and agree upon the requirements. Properly defined and agreed-upon requirements are crucial for the successful outcome of any project or initiative and the information captured is foundational to the Project Charter.

Contents:

• Introduction: Purpose and scope of the document (define what will and will not be covered in the document).
• Background: Provides context and high-level goals about why the project or product is being undertaken. This could include market changes, organizational needs, or customer demands.
• Stakeholder Identification: Lists and describes all stakeholders involved, detailing their roles, responsibilities, and how they will be impacted by the project.
• Business Opportunities/Requirements: Describe the opportunities the business aims to exploit, which led to the initiation of the project. This area will include functional and non-functional requirements, desired features, and user stories/personas.
• Constraints: List any constraints the project faces such as budget, technology, organizational capacity, or schedule requirements.
• Business Process Modeling: Diagraming and flow charts of the current state and future state business process.
• User Acceptance Criteria: Outlines the criteria the solution must meet for the project to be considered successful by the stakeholders.
• Assumptions and Dependencies: List any assumptions or dependencies known.
• Risks: List any known risks
• Approvals: acceptance of the document is foundational to the creation of the charter and aligning the delivery team to the needs of the business.

?

5. The Importance of the Discovery Phase

Conducting a Discovery Phase is critical to the success of any project. If the foundation of the project is weak or uncertain, it is more likely to face problems in the future. By dedicating time to a comprehensive discovery process, we can ensure that all stakeholders are on the same page, objectives are clear, and we can create the necessary foundational elements for the planning, design, and execution phases.

6. Common Challenges – RED FLAGS

Incomplete Information: Sometimes, stakeholders might not provide all necessary details, either due to lack of clarity or oversight. Projects that cannot exit the discovery phase with clear and concise artifacts should not continue until the information is clear.

Differing Visions: Different stakeholders might have varying ideas about the project's direction, leading to potential conflicts. This is less of an issue in simpler projects, but in large projects/programs, this is more common. Before exiting the discovery phase, stakeholder and vision alignment is critical to avoid potential conflict in later phases. Sponsors, SLT, Architecture, and a strong project team need to resolve this before moving to the next phase.

?

7. Wrapping Up

The Discovery Phase is crucial in setting the direction for a project. It's like the foundation of a building. If it's solid, the chances of success in the following phases are much higher. In our upcoming series, we'll delve deeper into each subsequent phase, providing valuable insights and best practices to ensure project success.

Stay tuned for the next article where we will explore the Planning Phase, a critical step where strategies are formed based on insights from the Discovery Phase.

?