As many PMP trainers will tell you, one of the advantages of enterprise wide PMP certification is that all of the PMs within the organization start using the same terminology. Everyone suddenly is able to speak in the same language. That’s a significant part of what we do when we work with clients. We often need to unpack the terminology that’s in use within the organization – and often we need to evaluate the actual practices being performed and map them to an EPM framework.
In this vein, it’s always impressive how much organizations attempt to pack into a project schedule. Often times, there are very disparate concepts that get thrown into a project schedule – which don’t make too much sense, and may present an obstacle to the organization actually managing projects effectively.
Phases and Lifecycles
Take the example of the word “phase.” The PMBOK defines a phase as a collection of tasks, usually culminating in the creation of a major deliverable. In the software world though, and I’m talking specifically about the world of Microsoft Project Server and SharePoint workflow, a phase implies that the project (or entity) is in a specific state, i.e. “Pending Authorization, Active, On Hold, Completed.” In effect, a lifecycle phase is a label that we apply to the project that is then inherited by all of the various entities that comprise a project: resource work, allocated cost.
In this way, we have cost that is associated with projects that are still pending approval, and we have cost that has been allocated to projects that are currently active. The phase label presents a convenient way of classifying this cost. If we use this mechanism, by default, a project may only exist in a single phase. For a project to exist in multiple phases at the same time typically requires that we model the project differently, i.e. as a program – where we have a program lifecycle that is comprised of multiple projects – and each project is in a distinct phase of the project lifecycle. In fact, I typically use that as a test to see if we’ve defined the phases correctly. If it’s possible to be in multiple phases at the same time, we didn’t get the lifecycle definitions correct.
So that’s how the term “phase” is now used in the world of PMIS system design. Now let’s talk “schedule.” On this, I tend to go with the PMI definitions, which state that the schedule is a static representation of a schedule model – with a schedule model being the accumulated logic and information related to a project combined to provide a predictive forecast of time, cost and effort. Each week, you input the latest developments into the model and generate a revised schedule.
This is where things may get confusing. Schedules often include a logical grouping of tasks – often called a phase. Note, however, that this is generally not the recommended way to structure a project schedule, as the general consensus in the scheduling world (at least within the circles I run in) is that schedules should tie directly back to the WBS, and a WBS should always be product oriented, not phase oriented.
Hence while a schedule model may be structured to map to a specific phase structure, that’s not necessarily required or even desirable. In fact, one could argue that a phase structure supersedes the actual schedule of a project – as it’s very rare to actually incorporate the preauthorization, business case development steps in the schedule – which doesn’t typically get developed until a bit later in the lifecycle. The same applies for post-project benefits analysis – which needs to occur, but is rarely incorporated into a project schedule.
On the other hand, it’s quite common to leverage the schedule model to forecast when a project will transition from one phase to another, i.e. to include milestones within the schedule that provide some prediction of when the project will progress to the next phase.
So we now have two terms which are often conflated:
- Phases – a specific definition of the status that a project is in within the project lifecycle – that definition being inherited downward to apply to all of the relevant component of the schedule model.
- Schedule Model – a simplified representation of the project schedule used to forecast time, cost and effort.
And the last item that often gets confused with these two, surprisingly enough, a checklist. What is a checklist? It’s a collection of tasks or conditions that must be met for a specific item to be declared completed. Sound familiar? Sounds kind of like a phase, i.e. we have a collection of things that must be completed before the project may move from preauthorized to authorized. Similarly, it sounds a lot like a schedule, which contains a series of tasks that must be completed for the project to be completed.
The difference is that a checklist defines either conditions that must be met – or tasks that must be completed, but those tasks are so small and granular that they are not worth including in the schedule model. We simply summarize the checklist process as a single task within the schedule, and capture the verification procedures that drive the checklist outside of the schedule. At least, that’s how it should work – too often we see clients incorporate the checklist into the schedule model and try to model overly granular tasks in the schedule.
Once we’ve unpacked these terms, we can focus on improving each one. Until that is done however, what we have is an unwieldy procedural mess.