In keeping with the Co-Manager model introduced in an earlier article, the Client Checkpoint is a major decision step in the ECPM Framework.
You can think of it as a StageGate that directs and channels project execution with the goal of maximizing delivered business value. Needless to say, meaningful client involvement in the Client Checkpoint is a Critical Success Factor (CSF) to the delivery of expected business value. The Client Checkpoint is structured around the well-known Input/Process/Output Process (shown below).
Figure 9.1: ECPM Framework IPO Process
It is described within the context of the ECPM Project Execution Phase and adapted to the PRINCE2 Framework.
CONDUCT CLIENT CHECKPOINT
The Client Checkpoint Phase is the critical juncture of the ECPM project’s past with its future. The past is defined by the updated solution from the just completed cycle and the current contents of the Scope Bank. The future will be drawn from the learning and discovery resulting from the just completed cycle. Early in the project, expect there to be several possible directions to consider. In this phase, the client team and the development team review everything that has been done and everything that has been discovered to craft the contents of the next cycle. There may be conflicting directions, so be prepared. This exercise must be done with care if the project has any hope of delivering an effective solution.
Related Article: Probative and Integrative Swim Lanes: A New Stage Planning Tool
Without a doubt, this is the most important phase of the ECPM. For it is here that the future of the ECPM project is revisited. The client team and the development team come together and assess what has been accomplished, what has been discovered and learned from the completed cycles, and what should be done in the cycle to come. The client team and the development team jointly perform a quality review of the features and functionality produced in the just completed cycle. It is compared to the requirements, and its part in the solution and the overall goal of maximum business value. Adjustments are made to the high-level plan and next cycle work, as appropriate. The sequence Cycle Plan–Cycle Build–Client Checkpoint is repeated until the time and cost budgets for this version have been expended, the project should be terminated because it is not converging on an acceptable solution, or an acceptable solution has been reached for this version and this version of the deliverables is complete and can be closed.
Together, both teams will analyze what has happened in the project so far and jointly decide what will happen in the project in the next cycle. This is a very creative and challenging part of an ECPM project. Project deliverables from the just completed cycle are discussed with the full participation of all. This is a characteristic of what I mean by “client-facing.” These discussions focus on what has to be done to maximize business value within the time and cost constraints established by the client (client-driven). I have often observed how the client and the team interact in these checkpoints. From those observations, it was obvious whether or not the project was moving along according to the principles and core values of the ECPM.
The Conduct Client Checkpoint Phase is a critical review that takes place after every Build Next Cycle Deliverables Phase is completed. During the phase, both the client team and the development team will benefit from several discovery and learning episodes. Variations to the version functionality will surface; alternative approaches to delivering certain functionality will be suggested; and, each team will learn through their continuous involvement with the other team. There is a definite synergy that will develop between the two teams. All of this must be considered along with the functionality that had originally been assigned to the next cycle. The result is a revised prioritization of functionality for the next cycle.
The most important thing to remember is not to speculate on the future. For the next cycle, prioritize only the functionality that you are certain will be in the final solution. That newly prioritized list will be input to deciding on the Integrative Swim Lanes for the coming cycle. The learning and discovery from the just completed Cycle Build Phase will be input to deciding on the Probative Swim Lanes for the coming cycle. The available resources and the resource requirements of the prioritized Integrative and Probative Swim Lanes will dictate the contents of the coming cycle.
There are a number of activities that take place during the Client Checkpoint. The clearest description is to use the familiar model: Input, Process, Output. Figure 10/1 is that model applied to the ECPM Client Checkpoint.
Input Data
The input data consists of the items listed in Figure 9.1:
- Planned versus actual deliverables
- Learning and discovery
- Probative swim land results
- Updated scope bank
- Status reports
- External environment
- Internal environment
- Updated RBS
Planned versus Actual Deliverables
At the end of a cycle, unfinished deliverables are returned to the Scope Bank for re-prioritization. As a result of learning and discovery of the just completed cycle, unfinished deliverables may never get a high enough priority to be completed in a later cycle. This is quite common, especially when you consider the fact that the work of the cycle build plan should be completed according to its priority. The question, then, is what is its priority with respect to other prioritized functions and features waiting in the Integrative Swim Lane list in the Scope Bank?
- Any functionality and features planned and integrated in the previous cycle
These are the deliverables from all previous Integrative Swim Lanes. In other words, the current solution. What was delivered will be used to update the solution through the RBS. So, the RBS is a hierarchical map of the current solution. It should be posted in the Team War Room. Through experience, I found that the updated RBS is one of the most visual artifacts produced in an ECPM project. I have also seen it used as an idea generator for planning Probative Swim Lane contents.
- Any functionality and features planned but not integrated in the previous cycle
A cycle ends when its time box expires, or if all planned deliverables are complete. What was planned in the Integrative Swim Lanes for the just completed cycle may not have happened for a variety of reasons. This is not the result of change. It is the result of running out of time or experiencing some other event that prevented the orderly completion of the cycle plan. Since the cycle time box is fixed, any schedule delays that cannot be recovered will result in some Integrative Swim Lane deliverables not being integrated into the solution in the just completed cycle. These incomplete deliverables will be returned to the Scope Bank for reprioritization and consideration in some later cycle.
Learning and Discovery
The client will need some time to evaluate the most recent contributions to the solution. That evaluation has two aspects to it. The first aspect will be the experimentation with the newly expanded solution, paying particular attention to the functions and features added in the just completed Integrative Swim Lanes. Are other changes suggested from what was just produced? The second aspect is the results from the Probative Swim Lanes. Did you learn about any new functions or features? Are there any clues about other parts of the solution yet to be built? Will additional Probative Swim Lanes be needed to define these discoveries further, or can they be planned for inclusion in the solution through future Integrative Swim Lanes?
Learning and discovery will involve an unedited cumulative list, including ideas generated in the just completed cycle and all other ideas not acted upon. Once acted upon, an idea might end up in a future Probative Swim Lane or Integrative Swim Lane. Until then, the idea remains in the Scope Bank.
- Any changes that took place in the business environment during the previous cycles
These changes will happen outside the control of the project team. A competitor introduces a new or upgraded product that competes directly with the deliverables you expect to produce in your project. This brings a TPM project to a screeching halt in almost every case, but that is not what happens on an ECPM project. Like a good athlete, the ECPM co-project managers anticipate such changes and can adjust accordingly. Whatever solution existed at the completion of the previous cycle may have sufficient business value to compete now. If not, all is not lost because the ECPM project can adjust deliverables going forward, and come into the market at a later time with expanded functionality and features.
Actual requirements are not static but, in fact, are quite dynamic. They can change several times throughout the life of the project for one or more of the following reasons:
- Changes in market
- Actions of a competitor
- Emergence of new or enhanced technologies
- Organizational priorities change
- Changes in sponsors
- Learning and discovery from a previous cycle
Probative Swim Lane Results
The Integrative Swim Lanes are well-defined, and the development and the cycle build plan established. The Probative Swim Lanes are very different. They can be highly speculative, and can change the depth of investigation and directions at any time. A good Probative Swim Lane investigation needs to be as adaptable as the situation dictates. The best return will be from a hands-off management style. Let the creative process unfold without any constraints except the cycle time box. The Probative Swim Lanes are designed to expand the depth and breadth of the solution. The major question is: Has anything been learned about further enhancements to the solution? A Probative Swim Lane has three results: to integrate; modify and repeat; or abandon.
1. Integrate: An enhancement to the solution has been identified.
Another piece to the solution puzzle has been discovered! It may have taken several Probative Swim Lanes spread over several cycles to reach that conclusion. The discovery may be so significant that a celebration is in order, but don’t order the pizza just yet! The solution piece needs to be documented and placed in the Integrative Swim Lane queue for prioritization and consideration in a future Integrative Swim Lane.
2. Modify and repeat: This direction may produce results and should be continued.
The idea shows promise. Continuing in the same direction or some other discovered direction will be appropriate. It needs to be documented and placed on the priority list for consideration in a future Probative Swim Lane.
3. Abandon: Nothing new has been identified, and this direction should be abandoned for the time being.
No idea is ever removed from the Scope Bank. What does not seem like a fruitful direction now may turn out to be valuable later in the project.
As work proceeds on a Probative Swim Lanes, results may suggest that the basis for the swim lane does not seem like a fruitful direction to pursue. The less that is known about the solution, the more likely will be that result. From experience, my best advice is not to “throw the baby out with the bathwater” too soon. I have experienced situations where a past Probative Swim Lane did not produce any immediate insight, but later provided an idea that did. Just remember to put all Probative Swim Lane results (both good and bad) in the Scope Bank for future reference.
Search for new functions and features
The less you know about the solution, the more challenging the identification of Probative Swim Lanes and the higher the risk that you will not find that solution at all. Because the project team is journeying into the unknown, do not be discouraged by short-term results. Sometimes, it will take several false starts before a promising direction is discovered. Even then, it may take several additional Probative Swim Lanes to explore a discovery fully, and then implement it through one or more Integrative Swim Lanes.
