As with most things, successful projects start with well-considered preparation. Here are a few suggestions as to how you can give your project the best chance of success before you open any apps.
These suggestions are largely pitched at infrastructure and building projects, but most of the comments hold true for ICT and process improvement projects as well.
What is success for your project?
→ Establish clear agreed project objectives and measures.
What is “success” for your project? How will you know when you’ve got there? Have you agreed on the project objectives and risks/constraints with the project sponsor?
All successful projects, whether they are engineering and building projects, ICT development projects or less tangible social development projects, start with clear agreed objectives and performance measures. In fact, the more intangible or qualitative the desired outcomes, the greater the need for clear objectives and measures.
The objectives should be project specific so that they are achievable within your accountability, rather than corporate objectives over which you have limited influence. You may need to re-work the project objectives so that they adequately describe the desired project outcomes, and are measurable and achievable within your accountability.
How “carte blanche” is your delegation and accountability?
→ Seek the maximum level of delegation to communicate, and clarity on approval to commit.
How far does your delegation extend? What can you commit to without seeking approval? Have you actually obtained any meaningful written delegation?
Effective project management requires the PM to be able to interact and collaborate across the whole organisation, and hopefully across the broader external environment, without travelling up and down the organisation hierarchy each time you need to communicate with key players in the delivery chain.
The key point here is to maximise your delegation to communicate widely, and not necessarily to make momentous or fundamental decisions. The latter is managed within the project’s governance framework.
How effective is the project’s governance framework?
→ Assist the organisation to operate an effective project governance framework.
It’s important to remember that the PM’s role is to deliver the project successfully, and not to invent project content or make arbitrary scoping and specification decisions. Accountability and decisions regarding project funding, scope and specifications are the role of the organisation, communicated via a project governance framework to which project management activity should be ultimately accountable.
You may have to assist the project sponsor to develop an effective project governance framework, identifying the ultimate accountability chain, and the key corporate players who have organisational accountability for funding, scoping, legal support, communication and technical compliance.
Whilst the existence of a corporate steering committee or similar may sometimes appear to be a burden from the PM’s perspective, if the project starts to experience difficulties, especially with stakeholders, then the governance framework will be of immense value to keep the project on track.
How mature is your organisation with respect to project management?
→ Recognise the level of project management maturity in your organisation.
PM maturity (the ability and structure to support effective project management) within an organisation is a key success factor. Mature organisations provide effective policy and guidelines for project management, low barriers to cross-functional communication (the near absence of silos and fiefdoms), and a range of templates and support material. The organisational role and status of the PM is understood and accepted. Organisational relationships are clear, and the staff are at ease with the duality of functional and process accountabilities.
On some occasions, the organisation’s project management maturity will be less than desirable, and unfortunately, this is an area that the individual PM can do little about directly. The best you can do is to recognise any management shortfalls and create your own systems and templates as you require. You may then be able to lobby for the organisation to accept your systems corporately.
Where did this project come from?
→ Understand the genesis of your project, and its associated risks.
Take some time to consider and identify the genesis of this project. Was it born out of careful planning, or was it hatched as a knee-jerk reaction to a perceived threat? Does the project have demonstrable corporate and stakeholder support, or is support a bit tenuous and narrow?
How is your organisational life as a PM likely to fare over the project lifecycle? Have you been handed a poisoned chalice, or a great opportunity just waiting to be delivered?
It’s important to understand the genesis of the project so that you can position yourself and your team accordingly. A thorough understanding of these aspects should also lead to the generation of project risks associated with the project’s history and climate, so that any difficult issues can be identified in advance and managed effectively.
How much prior documentation exists?
→ Identify and acknowledge all previous project documentation.
The amount of prior documentation will depend on the point at which the PM was invited to commence. Mature organisations appoint their PM early in the project lifecycle, and the PM will be there to see the development of the project development plan and procurement plan. It is likely that the business case will already have been finalised.
Whatever your point of entry, it’s critical that relevant project documentation exists, and that this documentation embodies the intent and legitimacy of your project within the organisation. The PM may have to initiate action to ensure that this documentation is formally signed off and published. The PM should also ensure that any gaps or unqualified risks are identified, acknowledged and rectified prior to proceeding with the project.
Are the project expectations realistic?
→ Understand the features and realism of the organisation’s project expectations.
The chances are that the business case that launched the project was developed and written by someone else. That someone else may have been an excellent business case writer, but they may also have carried forward some highly optimistic expectations for the project, including the budget and the benefits. Also, consider that often the business case author may not carry ultimate responsibility for project delivery.
There are several key factors that may lead to undue optimism. The first is standard optimism bias, which can understate the required budget and overstate benefits by at least 20%. The second factor is the human condition of being “eager to please”! Organisations or individuals that are eager to satisfy political or corporate expectations may trim off cost estimates, exaggerate benefits, and minimise risk contingencies in order the get the project over the line. The third factor is the preliminary state of the scope and design at the time of seeking approval for funds, meaning that the budget is based on a very thin concept design that would not normally be used for cost estimation. How thorough was the investigation and preparation for the project? Was the business case based on a thorough feasibility study, or was the feasibility planning skipped because of indications that the sponsor government or organisation wanted the project outcomes anyway?
Any unrealistic expectations or assumptions need to be highlighted and remedied before the project gets into its stride, otherwise, the PM will be continually perceived to be under-delivering.
What are the current expectations?
→ Ensure that project expectations and assumptions are contemporary.
If the project has been in gestation for a while the business case and any project planning material may not be current, and circumstances may have changed. The political or organisational climate may have moved on. The supplier market may have changed. Other projects or initiatives may have changed the risk profile of the project.
A brief review of the project documentation against the current landscape is valuable to give the PM confidence that the project is still viable. If there are any assumptions that don’t appear to hold up in the current climate, then this is the right time to flag them, and to seek modifications before the project builds up too much momentum.
Who are the key influencers and beneficiaries?
→ Stakeholder engagement planning is critical to project success.
Before getting too carried away with delivery planning, it’s worth reflecting on the nature of the key stakeholders. The stakeholders should be categorised in terms of key influencers (positive and negative), important technical support, passive communities and the ultimate beneficiaries.
With the rise of communications through social media, a relatively recent phenomenon is the impact of the “nimbys” – “not in my backyard” protesters. Major projects that deliver broad scale benefits can be derailed by a vocal nimby group, especially in swinging political electorates.
In addition, there are broader scale support or protest groups for virtually everything – building development, infrastructure development, environmental impact, education, social welfare, equality and more. These groups can mobilise very quickly, and the PM may be caught unawares through lack of stakeholder planning, or just simply naivety.
The development of a relevant and detailed stakeholder management & engagement plan is an essential first step in project delivery management. If the project involves internal process improvement, then the plan should morph into a detailed change management plan.
Who’s helping and who’s hindering?
→ Informally test the organisation climate for project support.
Check within the organisation to assess who’s helping and who’s hindering. Ideally, all key organisation personnel will be aligned and committed to the project, but it shouldn’t be taken for granted. Moreover, the alignment or non-alignment of key staff may not be overt, and written documentation and sign-offs may not tell the whole story. The PM should spend some time informally testing the organisational waters for any latent internal issues that may arise as the project is delivered.
You may have to develop an internal strategy to enlist the support of key organisation players to help manage and persuade the less committed internal stakeholders.
What are the key procurement and delivery risks?
→ Ensure that the project risk register is realistic and specific.
The project documentation will almost certainly include a comprehensive risk analysis – often so comprehensive that the really key practical risks are lost in amongst dozens of modest risks, or perhaps not accurately scored by the project planners. Often, the identified risk events and mitigation actions are too generic to be of much value, and they may have to be revisited to add project specificity. On occasions, some risk events may have been copied and pasted from other projects.
Check the extent of identified procurement risks and their practicality, and the risk score that has been attributed to the risk. Sometimes a thorough revision of the risk register is worthwhile, with assistance from procurement and delivery personnel. In fact, it is good practice to revisit and review the risk register at every new phase of the project, including post business case, project development plan, and then at the inception of the delivery phase.
How committed is your team?
→ Establish a competent and diverse project team.
How committed and competent is your team? Or have you actually even acquired a team yet? The team mix is extremely important. If you still have the luxury of nominating your team members, then try and ensure that the team comprises a suitable mix that demonstrates real diversity including technical orientation, process orientation, financial, social and environmental. Consider that the core full-time team could comprise a mix of generalist process-oriented and outcome-oriented people, supported by a part-time team of competent personnel representing each of the required professional disciplines. Lastly, avoid a predominance of alpha males!
The role of the Project Director
The more project-mature the organisation, the more likely that it will support the role of a Project Director (PD) who may manage a portfolio of projects each led by a subordinate PM. Or in some cases, the project may be of such size and/or complexity that a PD is appointed to a single project, supported by subordinate PMs.
If there is a PD appointed, then many of the activities identified in this paper are more likely to be directly pursued by this person, but the support of the PM is expected and necessary, and the PM’s role in these activities may not be diminished.
The role of the PMO
If your organisation is project management mature, then it is likely that it supports an effective Project Management Office (PMO) to provide the project management framework, guidelines and tools for PMs. Make the most use of their facilities, ensure your team’s compliance, and seek their personal help in managing your project structure. Don’t be shy in offering suggestions for improvement based on your practical application of their tools.
Celebrate little wins!
The daily work life of a PM and their team can be extraordinarily stressful and unrewarding, especially if some of the elements discussed here are absent. Your project will have “milestones” identified along the way, and you should take the time to celebrate the little wins as you proceed and acknowledge the work of yourself and your team as often as possible!