Your Project's Approved...Now What?

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 andy.jordan@roffensian.com. Andy's new book Risk Management for Project Driven Organizations is now available.

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.

Project deliverables
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.

ADVERTISEMENT

Trending Articles

Topic Teasers Vol. 40: Stakeholder Involvement

by Barbee Davis, MA, PHR, PMP, PMI-ACP

Question: I’ve just been an unwilling part of a total project train wreck. Management purchased a third-party software “solution” without any input from my team or any of the end users. Once it was on site, we had the impossible job of implementing it and rolling it out to the organization. What a disaster! I can’t change that, but how do I protect myself and my team from being involved in that kind of situation in the future?
A. Document the specifics of the failure so that you have data to show how and why this ultimately failed. At the same time, come up with steps you can take with your team to change your own and the team’s behavior when this happens again.
B. Managers who do not listen to the team and the end users deserve to fail and for the project--and ultimately the organization--to lose money. You can’t fight management, so just do your job and implement what they choose.
C. Set up a lunch-and-learn session as soon as you have collected enough incriminating evidence to show that management made a very poor business decision in this instance. Be very specific in who was responsible for this failure, and by doing this you will deflect blame from yourself and your team.
D. An agile team works on the premise that they are flexible. Despite incorrect third-party software being purchased, you and your team should have been able to re-write it so that it was what the company needed, whether they knew what they needed or not.
Pick your answer then Test Your Knowledge!

The Best Defense is a Good Offence?

by Andy Jordan

When project teams or project managers become territorial or confrontational, the situation needs to be addressed immediately--and professionally. Here we look at some of the causes of what is a fairly common communication problem, and how to address it.

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.

Project resources
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.

Conclusion
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 andy.jordan@roffensian.com. Andy is also on Twitter at RoffensianPM.


comments

Network:0


All good points, but in my opinion, a bit obvious for any PM. Still, good article, thanks.

ADVERTISEMENTS

"O, it is excellent To have a giant's strength! But it is tyrannous To use it like a giant."

- William Shakespeare

ADVERTISEMENT

Sponsors