When working on the complex tasks associated with configuring for combined hardware and software product deliverables--and the sharing that takes place between the technologies--it is important to have the right mix of teams in place in order to make project execution a less painful reality.
Your Project's Approved...Now What?
I love the feeling of a brand new project. The initiative has just been approved and everything is fresh and exciting. Nothing has gone wrong yet and it’s easy to believe that everything is going to go smoothly. Stakeholders are engaged, the sponsor is communicating and customers are thrilled to be working with the PM on the project. The start of the work is really the time when optimism is at its highest, when anything seems possible and when it’s easy to believe that this one’s going to be different.
Okay…reality check. It’s not going to last! But more seriously, how can we as PMs take advantage of those early days when everything seems positive? What should we be doing to ensure that the project starts as smoothly as possible?
The right start
The mistake that many project managers will make is that they will rush headlong into planning the project without first ensuring that the fundamental pieces of the project infrastructure are in place. I understand that there is a desire to show all of the stakeholders that you are on the ball and enthusiastic about making as much progress as possible as quickly as possible, but rushing into planning is like building the walls of the house before the foundation has been poured--it’s not going to deliver a good result.
Different organizations have different models for project initiation, with the biggest variables being driven by the requirements for project approval (i.e. what has to be completed before the project initiation begins?) and the amount of organizational control over the project structure (are teams assigned with the PM or is there freedom for the project manager to work with stakeholders to build the team?). Regardless of what is in place starting initiation, for me the following is needed by the end of the initiation work.
To distill this element of initiation down to a single comment, it’s about answering the question, “What does success look like?” The project will have been approved based on a number of expected benefits, but this now needs to be translated into something more precise. During initiation we need to finalize the scope--the tangible deliverables that the project will deliver (and just as importantly what it won’t deliver), and this needs to be reviewed and approved by all stakeholders. This is the first cornerstone of the foundation for the project--it’s an agreement that everyone involved in the project has the same understanding around what the project will deliver.
We need to go beyond this simple set of deliverables however to ensure that everything is as black and white as possible. We need to define some standards around our scope--to use a technology example we aren’t going to build a high-availability system, we are going to build something that is intended to be a 24/7/365 platform with no requirement for outages for maintenance and an uptime guarantee of 99.99 percent.
This element also needs to agree on things like delivery and major milestone dates, project budget, quality standards and risk tolerance. There may be less flexibility here based on organizational standards and/or the conditions of the project approval, but successful initiation requires the elimination of all assumptions in these areas.
During project initiation there will be fewer people working on the project. Many people won’t join the team until the project planning begins, but during initiation there will still need to be decisions taken around project resourcing, and some people will need to contribute to the scope work described above (if only on a part-time basis).
The most important resource-related work during initiation is the determination of how the project team will be built. There will likely need to be a tradeoff between the PM’s preferred approach of cherry picking each team member and the resource owners’ preference of assigning a resource based solely on their needs. While it’s not necessary to identify every specific person at this stage (some people may not be needed for many months), there does need to be agreement on the process for securing resources, the skill sets that are needed for key roles, etc. Again, the organizational approach to project management may also factor in to this--if the PMO owns resource allocation from a central resource pool, for example.
I also like to agree during initiation on how teams will be managed. This should only be broad guidelines, but agreeing with stakeholders on things like communication channels, explanation of the project background (understanding why a project is being undertaken is important for team member buy-in), and how conflict between operational and project work will be resolved can help to simplify things later in the project.
Project initiation is not one of the most exciting parts of a project, and it can be tempting to rush into planning where much more visible progress can be made. However, the investment made in effective project initiation will pay off over and over again. Like the house without a foundation, a project without initiation is doomed to fail.
Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at firstname.lastname@example.org. Andy is also on Twitter at RoffensianPM.
All good points, but in my opinion, a bit obvious for any PM.
Still, good article, thanks.