The Big Picture – Project Lifecycle Overview

Click Here for Larger Image

A picture is worth a thousand words so I thought I would start with a diagram. I recently had the need to explain an overview of the Project Lifecycle within the context of software development so I thought it would be worth sharing here. This diagram is by no means original or even possibly unique. The initiating, planning, executing (implementation), monitor and control and closing match the PMBOK definition for project process and the sub-processes are generally agreed upon across the industry, but everyone enjoys a good picture and so here is mine for explaining how things work.

While some of the sub-processes may software specific (HLD, DLD, system testing to name a few) the overall process is applicable to any field of interest. Here I will talk about the main processes (Initiation, Planning, Implementation, Monitor and Control and Closing). In subsequent articles, I will cover the sub-processes in more detail.

Enough of the background, let’s get started. This framework is meant to be used as a guide for moving through a project in a controlled way. The benefit of using a controlled approach are numerous: ensure that you work on the the most valuable projects (as defined by the organization through prioritization, rate of return, or some other method), ensure that the project is completed to the requirements, ensure that the project is completed in the shortest time possible. You get the idea. The naysayer will say that this doesn’t allow for creativity, I disagree. There are creative elements in each of the phases – what this doesn’t allow is for a project to get started, funded and move forward based only on the creative to only fail once it is realized that there is some key element that was missed during Initiation or Planning. The creativity and generation of ideas is the backbone of the project but most of us need to be smart with how we use our resources (money and human capital) and that necessitates that we can’t tackle all the great ideas at the same time. More on this later, but let’s get back to the task at hand, an overview of the major project processes.

Initiation

Initiation, which is some organizations is synonymous with project selection, is process for gathering and vetting project ideas with the ultimate goal of determining will project ideas will be authorized to move forward to the planning phase. This can be done informally or formally but generally includes a method to gather various ideas for future projects or features*. These can come from a variety of sources including customer requests, suggestions internal to the project team, legal requirements to name a few.  If there are enough incoming project ideas these will be gathered into a managed list or database to track their status. The balance of the initiation phase focuses on vetting these ideas. There are various quantitative and qualitative ways to do this which I will cover in detail when I discuss the sub-process “Advocate.”  Generally there is  a decision making body  (Steering Committee, Management Group, etc.) which has the responsibility for using the vetting data to render a decision as to whether this is a project or feature that should be taken on by the organization. This adds the project to the managed queue of projects waiting to be worked on. Depending on the particular organization the projects can be prioritized at this point to specify in what order projects will be tackled. Alternatively if a quantitative vetting process was conducted the prioritization will result as a by-project of that process.  For some groups this queue can become a list of tens or even in excess of 100 project ideas that are considered viable. In other organizations it may be a handful or only one project idea in which case this process is limited to the agreement that it is the right project to be taking on. The project manager may participate in the initiation phase, but is not the phase owner. The project manager has overall ownership for the Planning, Implementation, Monitor & Control, and Closing phases.

*Author’s Note: In software development features are often sub-components of functionality that are grouped together in a larger project for the purpose of managing a cohesive project throughout the lifecycle. Management of your inputs to the Initiation Phase can either be large projects or smaller features or components based on what matches the need in the organization.

Planning

Planning is the phase where the project manager takes the lead in clarifying and/or defining the objectives that the project was undertaken to address. Think of it this way, for every clarification action that takes place it is an opportunity for the Project Manager (PM) minimize risk and increase probability that the project will complete successfully. In this phase, the PM will develop several key documents including Project Charter, Project Scope, Initial Schedule Estimates, Initial Budget Estimates. In a controlled process, each of these documents will be reviewed by a designated Management Body. This could be the same steering committee from the intimation phase, or could be a project change control board specifically aligned for a particular project. Regardless, this body has decision making authority and responsibility for clarifying ambiguity at the project level so that the project team has a clear set of objectives to work against. Each of these documents should be reviewed in turn and signed-off on -literally signed off – to emphasize the commitment that is being made especially with regards to the Project Charter and Project Scope documents. This phase is largely executed by the PM but often leverages potential project team members for input into the project scope and schedule. It’s always good practice to make sure your teams are in alignment, and better yet, agreement as to what they are being signed up for. At the close of the Planning phase a project team should be gathered and ready to start on the Implementation. In reality, you might be gathering up resources, opening requisitions to fill resource gaps and in general seeing your resources trickle in as available. You may have even started some overlap of the phases, allowing some Implementation activities to start before you have completed all planning tasks. Doing this always enters a bit of risk into your project but the skilled project manager knows how to approach this prudently and minimize the risk and be aware of the reality that in real world projects we don’t always have the luxury of executing the ideal model.

Monitor & Control and Closing to follow shortly

Must-Have vs. Nice-to-Have Requirements

In addition to checking for solid requirements using the SMART methodology it is important to properly prioritize or categorize the project requirements. This can become especially critical in the large project or project with seemingly unrealistic expectations. There are many ways to categorize these; personally I like to apply the easily understood labels of must-have and nice-to-have.

SMART Requirements

In my opinion, requirements are the most under-rated aspect of most projects. In an unbelievable number of corporate projects they are completely non-existent and in the vast majority they are really no more than a paragraph or two of high-level requests which are unlikely to be delivered on successfully. In a very few of the countless projects I have worked on I have seen adequate, or an attempt at adequate, requirements. These projects, without fail, are the most successful projects that I have seen.

Why the passion, you ask? Without clear, complete and agreed upon requirements there is almost zero-chance, yes zero, that the project will be delivered successfully. And when I say successfully, I mean on-time, on-budget and matching the desired scope. Sure, most projects will get delivered without good requirements but you will see project delays (possibly numerous), budget overruns, and final scope that doesn’t satisfy the customer. Many people believe this is the way projects should progress or at the very least consider it a natural course for projects to take. This is not the case. Starting with adequate and thoughtful requirements can eliminate, or at the very least, significantly reduce, the amount of issues and re-work that are required in a project. So let’s start with the basics of requirements.

Project Example: The Triple Constraint

My goal with the project example is to create a scenario that is similar to those faced in real projects. I find, too often, that textbook examples overly simplify scenarios to the point that the answer is so obvious that when faced with a real world example the less experienced project manager cannot distill the issue.

Mark is a project manager for Custom BoatBuilders, Inc.* Bill manages the custom building of boats for private consumers. Consumers contract with Custom BoatBuilders (CBB) to build custom watercraft for personal use. Mark reports to Steven who is the Client Relationship Manager. Steven’s responsibility is to work directly with the customer and secure a contract for the building of a custom boat. After a new customer contract is signed, Steven involves Bill to execute on the project.

The Triple Constraint

Ah, the triple constraint, the cornerstone of project management and project management (PM) lingo. Along the way, I will try to cover the most common acronyms and lingo that are used in the discipline. I neither intend to promote nor condone any particular use, or in many cases, overuse, of project management lingo. My goal is to create familiarity with the terms as they are commonly used in practice.

The triple constraint refers to the three inputs that govern the ability to deliver a project. The three commonly agreed upon constraints are budget, time, and scope. They are often drawn in a triangular shape to represent the relationship between them. This triangular arrangement helps to represent that any adjustment to one of these factors will have an impact on the other two. This relationship will become clearer with examples. Let’s start with definitions:

Welcome

After thirteen years of project management experience, mostly in software engineering, I figured I had something to share. I have a lot of passion around the triple constraint (if you’re not sure what that is, read on) and I love to teach. I’m currently a project manager in the corporate environment and would rather be teaching, so I though I would start this blog to share my experience with those that are interested.

My goal is to post a series of topics that relate to project management and more specifically effective project and requirements management. This is not meant to mirror a textbook and is written in an extemporaneous fashion. I hope to get a few readers along the way and am very interested in requests for topics as well as questions readers may have as a result of topics posted or issues they are facing in their own projects or project disasters, whichever the case may be.