Developing and implementing a smart project management practice requires profound knowledge on the discipline. The project management discipline cannot be digested in one small bite as it encompasses knowledge of various domains and disciplines. It deals with complex specialties such as scope management, cost and time management, quality management, human resources management, communications management, integration and risk management, and it can overlap with other management disciplines. This chapter does not aspire to examine all of these domains but will take you through a journey to discover some of the most essential elements in managing projects.
When talking about project management and implementation methodologies, people spontaneously start talking about their phase-based approach. If you review the content pages of implementation partner's websites, you usually see diagrams illustrating a project lifecycle broken down in different phases and, when you attend commercial meetings between partners and their prospects, the explanation of the implementation approach is usually also done in terms of phases as follows.
This phased-based approach of a partner is inspired by the Microsoft Solutions Framework. A project run is executed and managed by five different phases. Each phase is closed by clearly defined milestone deliveries such as approved scope and project plans, scope completely executed, approved release readiness, and a complete deployment.
The following example shows an even more exotic variant of the phase-based approach, providing eight phases to manage the project:
Therefore, in most partner implementation methodologies, phases are important; but do we really understand what phases are and do we respect the phase-based practice in our daily projects? Let's try and find answers.
Phases represent a breakdown of the project lifecycle into smaller time units. Moving from one phase to the next, in a sequential manner, is typical for the waterfall model. The ambition of the waterfall model is to define requirements and designs quite early in the project lifecycle by means of separate phases. You can transition from one phase to another only when all the work planned for that phase has been done and all the necessary deliverables are produced and accepted. The following diagram shows the typical waterfall approach:
The essence of phases is that they increase the ability of management control based on the following idea: you cannot eat a whale in one bite but it must be digested in small pieces. The following diagrams shows two examples of a project approach.
Project A is organized in four planned phases. The activities are grouped and planned to be executed in their corresponding phase. The progress of execution will be monitored and controlled for each phase. The phases will be closed when all milestone deliverables are produced.
Project B is organized in one phase. All activities are planned to be executed in this phase. The phase will be closed when all deliverables have been produced. This phase will be closed along with project close out.
Let's assume that project A and B have exactly the same objectives, stakeholders, risks, timeframe, budget, and scope. What is the difference between project A and B? The teams will have to execute exactly the same activities in both projects, generating the same deliverables in the same timeframe and budget. The only difference is that project A is organized in four phases, while project B is executed in one and only one phase. In project A, the teams can start working on technical and functional designs only when the planned interviews, workshops, and documentation activities are finished and all deliverables are generated. This will be controlled and validated by both consulting and customer's project managers. In project B, teams might already have started developing before technical designs are ready and there are no real formal evaluation moments planned in between the activities and deliverables. So, the nature of the work is not changed, but by using phases, you control and validate the progress at defined moments. The purpose of this approach is to organize and control your timeline leading to more management control. Thus, the difference between project A and B is that in project A the ability of the project manager to really manage the progress is increased significantly, and therefore the chances of success are much higher in project A than in project B.
The following diagram shows a typical scenario that is most likely because of no controlled transition of phases in project B.
This typical scenario might unfold when not working with phases. The risk here is that activities and deliverables are systematically postponed. This causes a high concentration of to-do's at the end of the project lifecycle. This will bring on difficulties in planning and realizing a good deployment. In this scenario it is also common that no major problems have been reported until the deployment phase, which is not so surprising when most critical activities have been postponed to the end of the project lifecycle.
By the end of the project, the project manager will diagnose an increasing number of issues. Knowing that one train may hide another, it will not take long before the project manager realizes that the project is now starting a risky journey. A typical question is most likely to be: "why didn't we know about this earlier?" You can find the answer by just looking at the planning of such a project lifecycle—you are trying to eat the whale in one bite and this bite was badly planned.
If your implementation methodology includes a phase-based approach, and you really support this approach, then make sure you also implement a real phase-based practice. Just having named phases on your presentation slides will not really contribute to your real-life projects. Not respecting the phase-based approach reveals itself by the following characteristics:
- Not formally closing the phases
- Initiating new phases without finishing the planned deliverables from the previous phase
- Under planned and over planned phases
If you do not close your phases formally and move to upcoming phases without finalizing the work from previous phases, you are not respecting the elementary functioning of phases. This implies losing the benefits of this approach as well. It will not only cost you the ability to track your progress phase by phase, but you will also miss a great opportunity to work on your communication and closing culture with the customer. Implementing phases provides the great benefit of bringing in a closing culture on a step by-step basis. If you close each phase with a standard procedure, together with the customer, they will become quite familiar with closing throughout the project lifecycle. Building communication around these formal moments can only be to your advantage.
The following diagram illustrates a project lifecycle in which some phases are under planned and the others are over planned :
This diagram clearly shows an imbalance in the planning of activities spread over the phases. You can conclude from this diagram that this project is managed in two phases, instead of four, with an over planned deployment phase.
So, if you really want to work with a phase-based approach, you need to make sure that you respect the functioning of such an approach and you plan your phases in a balanced way. If you disregard these basic rules, then you must conclude that your implementation practice is not managed by phases.
Project management processes represent a logical grouping of activities, performed to produce a specified set of deliverables. Each time that you need to produce deliverables, you need to obtain validation for the goals, plan how you are going to execute, produce while simultaneous controlling this execution, and once ready, you need to close the assignment.
In the following diagram, you will find the project management processes as defined by PMBOK:
Initiating processes help you define and obtain authorization for the new project or phase. Planning processes help you establish the scope of the project, refine the objectives, and define the approach required to realize the objectives and deliverables of either the project or phase. The executing process group represents the activities performed to complete the planned deliverables. This will involve coordinating people and other resources to execute the plan. The processes required to track and review the progress and status regularly, to identify variances from plan, are gathered in the controlling process group. Once finished, each assignment, phase, or project should be formally closed by processes facilitating this closure. These processes are called the closing process group.
These processes are not the same as your phase breakdown of the project timeline. In fact, the project management processes occur (or should occur) in each of your phases. Depending on the phase, dominant processes will be in place. During the project preparation phases such as the diagnostic and analysis phase, initiating and planning processes can be more dominant, but this does not mean that those will be the only processes during that phase. You also need execution, controlling, and closing processes in your analysis phase.
It is important to notice that you always need to give attention to the closing processes. The closing process needs to happen in every phase or iteration. Closing is not something that you exclusively need to reserve for the end of your project lifecycle.
The diagram conveys that your planning outcome will direct the execution and controlling as a two-way traffic. How you execute will affect your planning, and the controlling can also reveal the necessity of planning changes. The same applies to the execution and controlling. Once you start executing the work necessary for producing the planned deliverables of that phase, you need to start monitoring and controlling; however, this needs to have an impact on your execution by means of corrective actions. If your monitoring has no impact on the execution, you might plough the sands.
If there is one thing you need to do to make you projects manageable, it will be breaking it up. You should be aware of the breakdown of your project lifecycle into smaller time units-like phases, but breaking down your scope is equally important. The best project plans are based on a good breakdown. You can find excellent project plans when buying toys for your kids (or for yourself). A good example is the Emergency-Doctor's Car from Lego. This includes a textbook project plan. The following image shows the best project plan in the world:
This image from the building instruction plan provides you with a clear definition of the scope. You will immediately know what to build and what not to build. The next image illustrates that Lego masters the skill of making rock-solid project plans. The building instruction plan is built up out of steps and subdeliverables. This building project will be executed in 13 steps, with each step producing clearly defined sub deliverables.
For example, in step 5 you need to produce this subdeliverable. You can start doing this only when you have finished step 4 and when subdeliverables 1, 2, and 3 have been assembled.
Each step has the same approach. For completing step 6, you need to have finished step 5 and produced additional subdeliverables in step 6. The Lego building instruction plans are excellent project plans based on the waterfall method, and the project management techniques of breakdown and the creation of subdeliverables. Were you aware that your kids have already mastered these techniques?
Most project management methodologies promote the use of Work Breakdown Structures, also known as WBS. A WBS is a fundamental project management technique, defining and organizing the total scope of a project by using a hierarchical tree structure.
In 1976, Russell D. Archibald, in his book named Managing High-Technology Programs and Projects, defined a WBS as a graphical portrayal of the project, exploding it in a level-by-level fashion, down to the degree of detail needed for effective planning and control. It must include all deliverable end items and the major functional tasks that must be performed.
The first two levels of the WBS define a set of planned outcomes that represent 100% of the project scope. A well-designed WBS describes planned deliverables instead of planned activities. These important deliverables are much more controllable than activities. We need to concentrate on what has been produced and not only on the effort: activity is not achievement. Deliverables or work that was not included in the WBS is not in scope of the project.
The following diagram illustrates a possible WBS structure for a Dynamics ERP project:
Your WBS might look like this but might be structured in a completely different way. The WBS Standardization Committee from PMI communicated the following:
Project managers may find themselves in many different situations and it would be inappropriate for PMI to place restrictions on their options. The WBS is a project management tool that can be used in different ways, depending upon the needs of the project manager. Therefore, there should not be arbitrary limits set on how the WBS should be created.
A WBS represents the way that the project manager plans to manage the project. This includes planning, estimation, and controlling, all based on the WBS. In this way, the WBS is your ultimate instrument for the integration of scope, cost, and time. It is also an excellent instrument to implement a "universal project language" within your project, making the project communication more comfortable.
We do not need to explain how important good estimates are in terms of the success of any project. Both time and cost estimates define your comfort zone within the upcoming project, and most of us, some time or the other, must have suffered from underestimated projects. Studies have identified that most of the cost overruns are caused by poor estimation skills. Furthermore, people generally tend to underestimate when asked for cost or time estimates for a new upcoming project, and we usually need to come up with estimates at times when detailed information on the project is not yet available. Nevertheless, stakeholders prefer accurate cost and time estimates in a context in which uncertainty is the only certainty. Higher accuracy demands greater effort and thus adds time and costs. And to make it complete, project estimation processes can't be bought off the shelf and there is no common industry benchmark for estimating a package implementation size. Getting close to despair? Wait, there are a lot of good estimation techniques documented and you can find plenty of literature on these matters.
One of the elements that we want to bring to your attention is one of the reasons why most of us tend to underestimate projects. Availability is a cognitive heuristic in which a decision maker relies upon knowledge that is readily available rather than examining other alternatives or procedures. In other words, people have difficulties imagining all the ways events can unfold, and out of sight equals out of mind. Therefore, we tend to assume that everything will go as we expect and this makes us overconfident in our estimation at the beginning of the project lifecycle.
Now what can we do? There are quite a few things we can try such as producing alternative scripts for how the project might unfold, drawing hierarchical diagrams of all that can go wrong, making explicit assumptions, and asking others to challenge us; we want to summon our WBS for duty. A WBS is an excellent tool in your estimation toolset and it will prevent you from assuming and forgetting too many things while estimating. The creation of the WBS will make you think of many possible events in your project. Even better is the use of template work breakdown structures. Those are work breakdown structures developed on the basis of previous projects. If you combine this with the use of project types for which you have an associated template WBS, your estimation accuracy will most certainly increase.
Another element that we want to bring to your attention is the subject of your estimation. We usually estimate the solution size or package complexity, including things such as the configuration effort to suit the requirements of business processes and the effort to produce custom objects to address the gaps in the application. In this context, we also evaluate the implementation and business complexity, but we sometimes forget to take the organizational complexity into consideration. Recent studies have identified that the implementation effort not only grows with the number of modules and submodules that are selected for the implementation, but that each user adds an organization component of costs. We need to make sure that we include all the complexity in our estimation scope. This might also be really relevant when we implement our solution in different departments of our customer's organization. The different departments might have different number of users, and they can have various experience and skills in terms of software solutions and procedures. The following diagram illustrates how you can organize your WBS in such a way that it will facilitate the estimation of the different complexities in the different departments:
You can only follow up what you have planned and estimated for. Project reporting is in some cases disconnected from what was planned and estimated. The breakdown used for the estimation and initial offer can be quite different from the activities planned and controlled later on. It looks as if the estimation, planning, and monitoring live their own lives. You cannot expect great results in terms of manageability, and cost and time overruns have a high probability in those cases. The WBS is used for defining work packages and developing and tracking the cost and schedule for the project. Once you have your deliverables and work packages defined and planned, you can easily follow them up using different possible monitoring techniques.
A technique that you can consider using is the "Earned Value Concept". In their book named Earned Value Project Management, Quentin W. Fleming and Joel M. Koppelman describe the focus of earned value as the accurate measurement of physical performance against a detailed plan to allow for the accurate prediction of the final costs and schedule results for a given project. They also state that the WBS is an integral part of the earned value concept. The reason for this is that the earned value concept requires the integration of the technical scope of work with the time commitments and the authorized resources.
The following diagram illustrates the benefits from the WBS in your projects:
The WBS is your starting point and control point in making estimates and planning derived from activity lists. It is the necessary integration instrument for making monitoring and reporting activities possible, and it acts as a global communication instrument throughout the complete project. These are significant benefits from an easy-to-use instrument and therefore worthwhile to use in your own implementation practice.