now browsing by category
Scope creep is highly pervasive! Once you’ve got it, you can’t get rid of it! The solution is pre-emptive action.
Scope and cost creep are probably the most influential factors in project cost/time blowouts, and yet there are effective ways to minimise the risk of creep at the very start of the project.
Scope and cost creep usually have their genesis in one or more of the following elements:
- Lack of recognition of cost/time escalation and risk;
- Incremental physical additions to the project deliverables;
- Limited original scoping and estimating accuracy; and
- Progressive escalation in the specifications.
Many projects have their projected cost and time adjusted legitimately, but still suffer unjustified criticism and loss of reputation. Some projects fail to recognise and respond to cost and time implications, and then receive criticism that is probably well justified.
Physical additions include extra deliverables and extra constraints progressively added to the project task such as extra floor space added to a building, increased IT user requirements, extra amenities added to infrastructure, or the imposition of external constraints, without associated cost and time recognition.
The original scoping and estimating accuracy can vary significantly between projects, but importantly it needs to be recognised that the original scope definition and costing have usually been performed prior to the business case, and their accuracy depends on the level of design achieved at that time. Usually, the early design is conceptual, and cost estimation is based on historical grossed-up unit rates for similar projects. Consequently, significant risk contingencies may need to be applied at this stage.
Escalating specifications include the progressive ramping up of minimum acceptance standards for materials, systems, manufacturing, storage and transport, again without cost and time recognition.
If left unchecked, much of this escalation will occur in the period between the acceptance of the original design and costing that underpinned the business case and project development plan, and the issue of the detailed design for construction or system build. Any further escalation during the build phase will most likely be caused by ambiguities that were ignored or missed earlier or latent conditions for which insufficient contingency was adopted from the outset.
The critical drivers associated with minimizing the occurrence and/or impact of scope and cost creep include:
- Project governance and management structure;
- Key stakeholder management;
- Balanced business and technical influence;
- Project management methodology;
- Realistic risk contingency provisions;
- Risk-based planning and investigation; and
- Understanding of, and exposure to, progressive earned value.
These are discussed in turn below.
Project governance and management structure
The design and adoption of an effective governance and management structure is fundamental to the project. The structure must be relevant to the project, clearly identifying roles and accountabilities. Some important considerations must be satisfied:
- Who is the project sponsor, and who is the beneficiary?
- Who holds and approves the funding?
- Who has ultimate accountability for technical standards?
- Who does the project manager report to?
- Who has ultimate accountability for delivery?
- How are internal and external stakeholders identified and engaged with?
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 responsibility of the sponsoring organization, communicated via a project governance framework to which project management activity should be ultimately accountable.
The PM 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 legitimate 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.
Key stakeholder management
The development of a relevant and detailed stakeholder management & engagement plan is an essential first step in project delivery management. The details of the stakeholder management plan should then manifest as a structural feature of the project by the formation of a working group or other communication method.
Key internal and external stakeholders must be acknowledged, listened to, and responded to as appropriate, and importantly those stakeholders must perceive and believe that their contributions have been acknowledged.
The role of the stakeholders becomes vitally important if any changes are contemplated – to scope, cost and/or time. Their response to proposed changes will represent an effective proxy for the wider community and may influence the project delivery and marketing approach.
If changes to cost and time are identified, then it is vital that all of the key stakeholders recognise the need for the change, endorse it, and are prepared to advocate for the change within the organisation and also the wider community.
Balanced business and technical influence
A peculiar feature of some organisations is the propensity for technical experts to dictate minimum technical specifications without challenge from elsewhere. If left unchallenged, a technically complex project may suffer from the impact of rampant technical enthusiasm on multiple fronts, each contributing incrementally to increased cost and time.
An effective balance to unchecked technical aspirations is the inclusion of a corporate business manager whose role is to challenge technical and scope matters from a business perspective, generally on a relative basis, and to drive decision-making always from an incremental value viewpoint, as well as reference to the available budget.
This also raises the issue of minimum “whole of life” (WOL) cost which is often stated as a tender conformance policy by the owner. The existence of a WOL policy is an open door for the enthusiastic ramping up of technical specifications. In addition, for a project that is being tendered in the open market, the WOL concept is fraught with difficulty, because usually, the owner has not stated what WOL actually means! Tenderers are still obliged to tender a competitive price which is unlikely to include a price premium reflecting a promise of long term savings over the life of the asset.
In addition to the inclusion of a business manager, the project may also use value management techniques and workshops, attended by the appropriate balance of people, to reach a position on scope and technical changes.
Project management methodology
A well structured and communicated project management methodology will ensure that the events that usually underpin potential scope creep are identified and managed early within the project management framework, and without exposing the PM to unnecessary personal risk.
All informal pressures to increase the project scope or to ramp up the technical specifications need to be referred to the relevant functional manager, or ultimately to the project governance team for resolution.
The PM should always work within the scope and specification agreed by the project governance team, which may, of course, vary over time if endorsed by the organization.
Realistic risk contingency provisions
As with WOL discussed earlier, the application of an appropriate risk contingency is often underplayed.
The realistic application of risk contingency is important right from the project outset. The original estimating process will likely have been based on low scope definition, and a conceptual design. Accurate costing is unlikely to occur until much later in the process, once detailed design has been completed, and this may well be by the tenderers, not the owner.
The owner may well include a suitable risk contingency in their budget estimating process, but how does this contingency survive in a highly competitive tendering market? Chances are that tenderers will minimise their estimate of the risk contingency in an effort to keep their price competitive, and hope that they will be successful in a subsequent variation claim should that risk eventuate. A successful variation claim will contribute to project cost creep, whereas an unsuccessful claim may adversely impact the contractor’s margin, and even put project completion at risk.
Also consider the impact of “optimism bias” which may operate to cause project managers and others to underestimate the probability and consequence of identified risks.
Consider also the business ethics where the owner has factored into the budget a realistic risk contingency, and yet it is believed that the successful tenderer has minimised the risk contingency to remain competitive. Is it entirely reasonable that the contractor should bear that risk, or should it be shared, or even excluded?
One solution is for the owner to bear responsibility for a particular risk, and identify a provisional sum that will activate in the event that such a risk eventuates, and be drawn down on the basis of demonstrated costs. That provisional sum is then included in the project budget estimates.
However great care needs to be applied in the design of, and subsequent evaluation of claims against a provisional sum, as some contractors may attempt to load their provisional sum claim to lessen the internal cost impact related to other claim items. There are techniques that can be applied to minimize such behaviour, and these would need a separate discussion to explain fully.
Risk-based planning and investigation
It is not sufficient to identify and cost risks and to provide an impressive risk register. You actually have to do something about these risks! Again, it is insufficient to believe that you have treated these risks adequately by writing a plan or procedure!
The key point here is that the owner and PM need to manage identified project risks both by:
- Designing out key risks by appropriate planning, investigations, and design/specification modifications; and
- Applying appropriate residual risk contingencies that are able to be preserved through the tender and contract award processes.
The decision about the extent of owner-initiated investigations worth applying to the project to mitigate risk can be aided by a fairly simple probabilistic analysis. That is, will the cost of investigations be significantly less than the probabilistic (likelihood x consequence) cost of that risk actually occurring? If so, then the investigations are probably worth doing, and the results shared with tenderers. The result of these investigations will inform the scope and specification for the project, and if the latent risk event was actually found to exist, then either the risk can be designed out, or identified as a legitimate estimated cost.
Similarly, the cost of more intensive early design for selected high-risk elements follows the same logic and again will yield a greater degree of cost certainty.
On occasions, there may be some reticence about spending project funds on investigations. However, if you were to ask the owner’s executive about their key financial expectations, usually the executive will indicate that cost certainty, not minimum cost, is their major worry. So, well thought out investigations will contribute to cost certainty and executive confidence.
Understanding of and exposure to progressive earned value
Earned value techniques are essential in managing progressive project cost, especially in complex projects with several work fronts.
However, in a classic lump sum or even a schedule of rates contract, time-based earned value information is managed by the contractor, and only available to the contractor. The owner simply receives the contractor’s cost claims based on an agreed pricing schedule, either conforming or as a variation claim. The owner may be blissfully unaware of what is happening “below the waterline”, and how hard the contractor is “paddling”.
Enlightened contracts require the contractor to tender a detailed costed work breakdown structure, and for the successful tenderer, as the contractor, to furnish progressive earned value reports for review between the owner and the contractor.
I have had a several conversations recently, both with colleagues and other project management professionals, around the topic of how to become a program manager.
Here are some of my thoughts on the career progression to program management.
Program management is a natural progression for many experienced project managers. Being a successful program manager, however, is more than having a PgMP certification. Program managers are expected to manage complex projects and have the interpersonal skills to be able to navigate business strategy and executive relationships.
There are many career rewards for a career path into program management. On average, program managers have higher annual salaries, tackle greater business challenges, work closely with customers, have opportunities to mentor project managers and even grow into executive suite careers. However, steps to transition from project to program management are not always obvious and some professionals struggle with the career transition.
Is program management right for you?
From the outside, it may be difficult to know if this career path is the right one for you. Program management is not simply managing ‘larger projects’ or a group of projects or managing project managers. Programs are about business objectives and business operations. They have much longer durations than projects. Program managers need to be focused on organizational priorities and business objectives, more so than delivery of a product or service. Program managers may even need to cancel projects based on a change in strategy or lack of business benefits.
How do I transition from project management to program management?
Like other transitions in life, a project manager will need new skills and a different attitude to succeed in program management. Skills such as organizational governance, strategy and navigating executive relationships are key parts of success in program management. Project managers who desire to make the transition should make their goals known to both internal and external networks and actively look for program management opportunities.
Pursuing a PgMP certification will help an individual stand out from the crowd. The real value of the PgMP certification is in the knowledge gained by studying for the certification. The preparation requires the project manager not only to study program management concepts and terminology, but to see the relevance of those terms and concepts working as a program manager.
What mindset changes are required for a transition to program management?
Taking on a program management role requires a mindset change to move from the tactical to the strategic. From my perspective, the first thing that surprised me was that I was responsible for program outcomes without having a direct line of sight to all aspects of a project as when I was a project manager. In short, I was responsible for the program’s overall success, but had to rely on others to manage the details. A change of mindset was also required.
As a program manager, there is more focus on business and the delivery of benefits. I also began to have more interaction with executive-level leadership and spent more time building relations with key stakeholders. I began to spend more time thinking about how to structure and govern the program, how to organize the projects within the program, to achieve the business strategy. I spent more time identifying and managing inter-project or inter-organizational risks.
I welcome any feedback or comments from others on their on their career transition from project to program management.
As project managers, we often tend to think and act like we own the projects we manage. In reality, we don’t. Usually, a number of players have an ownership stake, with the sponsor having the final say.
All those players, in John Kotter’s words, form the “guiding coalition”. The more focused and organized that group is, the greater the chance of project success.
However, change to the key stakeholders, the decision-makers in the guiding coalition, can derail the most well-run project. Here’s a case where the project manager did a masterful job of managing a number of key stakeholder changes to keep the guiding coalition functioning at peak efficiency and deliver a successful outcome.
Thanks to L.D. for the details on this case.
This wholesale building materials company had operated successfully for decades using a variety of mostly homegrown legacy applications, built with legacy tools and running on disparate legacy technologies. But, the times they were a-changin.
More and more, their retail customers were looking for tighter technology tie-ins, on inventory, ordering, billing, delivery status, and customer service. The privately held company was also getting pressure from its owners to increase profitability. The returns and growth have been consistently excellent over decades but the owners thought more was possible, especially given the old technologies the company was using. Finally, there had been a steady increase in turnover in their IT organizations, from programmers who wanted to work with something more than Cobol and Visual Basic, from the Computer Operations staff who wanted exposure to something more than IBM mainframes and Windows 7 machines and from the PMO and project management staff who wanted bigger, more challenging projects.
The CEO got the message. Things had to change. So, he formed an internal triumvirate to help him figure out what they needed to do and how to get it done without blowing up the company in the process. The triumvirate included the VP of Business Operations, the CFO and the CIO. To that group, he added an external consultant and long-time friend who had been his sounding board and confidant for many years. He called the group the Fab Five.
The Fab Five took a number of days over a three month period to figure out how best to tackle the challenge and map out a strategy that would see the business transform over time in a high return low-risk manner. They established the following goal.
To transform the capabilities of our people, operations, and technologies, working together to address the needs of our customers and suppliers while delivering a foundation for future growth and prosperity. We expect to spend up to $3 million over five years and achieve a 25% return on investment within the following boundaries:
- The specific scope and priorities will be established as the initiative progresses.
- We will seek to minimize operational change while maximizing value.
- We expect implementations to take place at least every six months to manage risk, gain experience and deliver value progressively.
- The key to our success will be the skills and talents of the people involved, including those who are with us today and those who will join us to help us on our journey.
Through discussions with the consultant, the Big Five agreed on a Project Director to lead the transformation program. He had extensive project experience in the ERP field, a stellar track record, and superb, bullet-proof references. We’ll call him Michael.
The first order of business when Michael arrived on the scene was to determine who the key stakeholders were and what roles they were playing. Michael’s first take on the program’s guiding coalition had the CEO as sponsor, the VP of Business Operations, the CFO and CIO as targets and the consultant as a change agent. Michael’s own role was as a change agent as well. With Michael’s arrival, the Fab Five became the Big Six.
Michael recognized some gaps in the decision-making group and suggested adding the Sales VP to the Big Six in a target role. The recommendation was approved and the Big Six then became the Super Seven, the group that would drive the transformation program through to completion.
Michael also recognized the importance of the company’s customers and suppliers going forward and so, with the approval and involvement of the other Super Seven members, he formed customer and supplier groups. That was a challenge because individual companies didn’t always want to share, so he also established key contacts with vital suppliers and customers to provide advice and feedback. Both the groups and key contacts would function in a target role.
As the guiding coalition was taking shape, Michael also started to form his transformation team. It included two architects, one an external contractor he had worked with previously and the senior architect from the company’s IT organization. He also added two senior software developers, one external and one internal, a process manager from HR, a senior Operations manager, SME’s from the core business operations and a senior member of the Internal Audit staff. Michael always liked to have the Internal Audit group engaged from the start.
With the core team in place, Michael launched a three-pronged analysis phase covering organization, procedures, people and technology perspectives:
- A process and functional strengths, weaknesses, opportunities, and threats (SWOT) review
- A SWOT review from the customers’ standpoint
- A SWOT review from the suppliers’ standpoint
As the SWOT reviews were being wrapped up, the transformation team developed a scope and priorities draft using a MUSCOW categorization (Must, Should, Could and Would) and reviewed it with the Super Seven. As a result of that review, a number of changes were made to the scope and priorities. The Super Seven members reviewed the resulting material with their teams with facilitation assistance from the transformation team members. Feedback out of that process was incorporated into the baseline scope and priorities and approved by the Super Seven for program launch.
After three months, the organization had agreed to the program’s scope and priorities and so set about considering alternative solutions. A key decision that emerged from the scope and priority deliberations was the question of buy versus build. The deliberations concluded that the end to end performance of the core business processes, not customization, was the most significant driver in maximizing value and positioning for the future. Therefore the decision was made to buy the software and/or technology services rather than to build in-house. That decision was reinforced by the realization that buying could deliver the required capabilities much more quickly and at less cost and risk.
The dialogue with the company’s customers and suppliers had identified three potential ERP software/service vendors. A review of the company’s competition and the market players added one more candidate to the list.
An RFQ was issued to the four vendor candidates based on the scope and priority work. Three of the four vendors responded to the RFQ and within six weeks of the RFQ being issued, a vendor was selected and approved.
A project manager from the selected vendor was added to the Super Seven and the group was renamed the Great Eight. Michael and his team worked with the selected vendor to ensure they fully understood the scope and priorities, to build the release plan and assemble the team to deliver the project. The fact that the project was recognized as a corporate priority throughout the organization and actively lead by the CEO and the senior management team made getting the right resources (people, facilities, funding) a walk in the park.
As the work got underway on the first release, disaster struck. The CEO, the program’s leader, and sponsor died from a massive heart attack. As the company mourned his loss, the VP of Business Operations filled in as acting CEO and project sponsor and work on the project continued.
After three months, a new CEO was appointed. He was an outsider with no experience in the building materials space. Michael managed to arrange an early appointment with the new CEO to brief him on the project and his vital role as sponsor. The new CEO didn’t buy it. He stated “I’m not the project manager. That’s your job. Get on with it”. Michael was taken aback.
Over the following six weeks, with the relentless support of the other Great Eight members, Michael explained what the sponsor role involved and why the CEO was the only one who could fill that role. He relied on a tool he had used many times before called Are You Ready to be a Sponsor. Michael explained the significance of the program to the current and future viability of the organization. He also reminded the new CEO of the owners’ desire to get a greater return from their investment as a significant reason for the CEO to lead the change. He pointed to decisions that had been made to date that were only the CEO’s to make. He identified future decisions that would need to be made and asked the CEO who else should make those decisions. The CEO usually acknowledged, often after some debate, that they were his to make.
Initially, Michael struggled to get even 30 minutes of the new CEO’s time. However, after each meeting discussing the CEO’s role and the progress of the project, the new CEO was a little more interested, a bit more informed and somewhat more inclined to be involved. Finally, the new CEO acknowledged his responsibility for the initiative and agreed to fill the sponsor role. The Great Eight was back to eight members.
Work progressed on the first release under the guidance of the Great Eight until its implementation seven months after the program launch. The delivery was a bit late and a tad over budget but the affected customers were thrilled with the incremental functionality, performance, and quality. Internal polling of the company’s staff revealed a high degree of support and satisfaction as well. So the Great Eight were thrilled too.
The second and third releases were delivered over the next nine months, mostly on plan and estimate, with rave reviews from all involved. As the fourth release was midway through its plan, disaster struck again. The owners had sold the company to a venture capital firm. In short order, the new CEO was replaced as was the CFO. The Great Eight was now down to six members and without a sponsor.
Michael and the remaining coalition members sought an early meeting with the new owners. In the meantime, they kept the fourth release going in the hopes that it would be a worthwhile investment. They recognized that suspending the work would not necessarily yield significant savings in the short term and would impede their ability to restart the work if they did ultimately receive approval to continue.
Fortunately, Michael and his colleagues did get an early hearing. Also, fortunately, they had a roadmap to follow for how to bring new key stakeholders up to speed quickly and effectively using the approach that had worked with the previously new CEO a couple of years prior. And fortunately, the new owners liked what they heard and gave their blessing for the project to continue as planned. Michael and his colleagues used the same approach to bring the new CEO and CFO up to speed and get them fully engaged. In less than a month, the Great Eight was back!
The fourth release and two subsequent releases were completed successfully to finalize the planned transformation. The total cost was $3.7 million, somewhat in excess of the budget but fully managed by the Great Eight. Actual ROI was 32% versus the 25% target. Staff turnover in IT declined to near zero from the time the program was introduced. It seems the company’s software developers, IT Operations staff and project managers were excited by the new direction.
Surveys of the company’s customers and suppliers found they were almost universally positive about the changes and the part they played. The company became a highly valued reference account for the vendor. And Michael, the Project Director, went on to manage a number of similar programs for the company’s new owners, the venture capital firm. They were obviously duly impressed with the job he had done and the results he had achieved.
How a Great Leader Delivered
Michael did a lot of things right on this initiative but the dominant theme here is the masterful job he did in managing the changes to the key stakeholder group. In fact, three lessons stand out:
- Know your key stakeholders – know and articulate the roles of all key decision-makers involved in your project and make sure the key roles – sponsor, target and change agent – are filled appropriately. If there’s someone who can play the role of champion, all the better. On the other hand, we’ve all seen a “steering committee” with assorted players who are unsure of their roles and responsibilities. Its function too often evolves to being a critic and shooting the messenger, usually the project manager. We know what damage that can do to an individual’s health and welfare and to overall project performance.
In this case, the membership in the guiding coalition was explicit and well communicated. The CEO started the process with his Fab Five. Michael continued to guide the evolution of the group to the final Great Eight. It was a “Goldilocks” group – not too big, not too small, just right! That significantly amplified their effectiveness.
If anybody tries to push their way into the guiding coalition without having a decision-making need to be involved or a formal role to play, keep them out of that body. More doesn’t always make merrier. For more on this, see Managing Project Interlopers
- Use best practices to create and direct the guiding coalition – Michael used a typical change management organization model – sponsor, target, change agent. Everyone in the guiding coalition knew the model and everyone’s role in the program which enhanced communication and decision-making effectiveness. He also used the “Are You Ready to be a Sponsor” template to help new additions to the guiding coalition to make the leap to full, effective membership.
There are others models available. Select one that works for your project and organization. But, make sure you pick one that includes the target role. A target is a manager (decision-maker) who directs the individuals or groups who must actually change the way they think and work for a change to be successful. A target’s sole responsibility is to ensure that his or her organization will operate successfully after a change is implemented. It’s an essential and powerful foil to the sponsor’s demands and is as vital to a change’s success prospects as the sponsor and change agent roles.
Targets can also include managers who are external to the organization initiating the change, such as customers, vendors, partners, and distributors. Michael did form customer and suppliers groups and identified key customer and supplier contacts but he didn’t give them a spot at the guiding coalition’s table. Instead, their interests were looked after by specific Great Eight members.
For more on the stakeholder model, see A Great Project Manager – the Sponsor’s Best Friend. I’d add a target’s best friend as well.
- Actively engage new key stakeholders – if your project has a change in key stakeholders, the decision-makers, do whatever you can to get the new player(s) identified and engaged as quickly as possible. They need to be brought up to speed on the decisions that have been made, the rationale for those decisions and the decisions yet to come. Otherwise, that knowledge gap will be a drag on the guiding coalition, on the new stakeholder’s commitment and performance and on the project as a whole.
In this case, Michael managed to bring the Sales VP, the vendor’s project manager, a new CFO and two new CEO’s up to speed quickly and minimize the impact of those changes on the program’s progress. Also, while this case focused on the key stakeholders, the same urgency for building currency applies to all those affected by the change. For more on this, see Coping with Stakeholder Change.
Having an effective guiding coalition for a project is THE key success factor. It drives every decision that follows. So, put these points on your checklist of things to consider so your project can have a great guiding coalition and you too can be a Great Leader. Also remember, use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process, and Decision Framework best practices right up front so you don’t overlook these key success factors.
Finally, thanks to everyone who has willingly shared their experiences for presentation on this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks
Written by Paul Taplin
If you want a really good project outcome, close down your PM apps and tools for a few days, and just reflect on the nature of the new project you’ve just been handed!
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!
Written by George Pitagorsky
The sense of belonging to a team increases an individual’s commitment to working towards a common goal in synergy with others.
Social belonging was recognized by Abraham Maslow as a critical human need, following physiological and safety needs in his hierarchy. This need and the need for esteem or recognition, combine in project teams to become important to optimizing team performance.
Belonging to a team takes different forms. Sometimes it means being in the center, part of decision making and implementation. Sometimes it is being on the periphery as a doer as opposed to the decision maker, or as part of a broader team (say, a department or organization) just looking on as others do their thing. in most situations, people are members of multiple teams simultaneously, for example, on multiple projects as a member of a functional group.
Belonging is a natural aspect of social relationships. It appears whenever groups form. In the workplace, particularly in projects, the sense of belonging fuels productivity because it contributes to open and meaningful conversation, the avoidance of unnecessary conflict, and maximizing the effective use of each members skills and knowledge.
Belonging is influenced by communication and clarity regarding expectations, roles and responsibilities within established work processes, mutual respect and caring, a sense of familiarity, and commitment to common goals and values. Belonging is a perception held by the members of the team based on a combination of concrete rules and boundaries as well as subjective feelings. The less formal the team’s definition the more subjective feelings drive the sense of belonging.
When subjectivity is in play, an individual may be perceived as a team member by the other members but not feel that he or she belongs. Another team member may feel as a member of the team while the rest of the team doesn’t.
In the fairy tale of the sleeping beauty, a princess is put into a lengthy sleep, only to be awakened by the kiss of a Prince. The curse of a 100-year sleep was a reprieve from the death curse imposed by a fairy who was overlooked by the princess’ parents when the child’s birth was celebrated. The moral of this story is “If you leave a stakeholder out of your team, he or she might curse your project.
A project team has core team stakeholders, those who are usually there for the duration and play key roles. Others play a variety of roles, each with a specific duration of involvement and impact on the project’s performance. When these roles and relationships are defined in a project charter, the understanding of who is on the team is more likely to be mutually understood. Hierarchies fade away when the team realizes that every role us needed too achieve objectives.
The players who are not on the core team are part of the project team. It is easy to understand that the team required to accomplish the project’s objectives is far larger and more complex than the core team.
When the peripheral stakeholders are formally engaged as team members and reminded of their belonging and ability to share in the project’s victory (or defeat), they are more likely to promote the welfare of the team. When they do not see themselves as team members, they may withhold information, fail to work optimally, withhold constructive criticism or to work against the team’s best interests. When a team does not recognize a peripheral player as a team member, it loses valuable input and may create unnecessary conflict.
Case of the Left-Out Manager
In a business project to implement a sales campaign, the time constraint was tight and there were several technical, legal and procedural issues that had to be resolved in order to release the campaign across multiple media.
A functional manager, Chuck, was not engaged, though, a couple of members of his department were involved. The team, under time pressure, felt they would be more likely to be successful if they limited the team to the smallest number of players and limited the number of alternative views on how best to proceed. Chuck felt slighted and was of the opinion that the team was taking a less effective approach than the one he would have recommended. While not overtly addressing the issue, side comments, body language and other “tells” made Chuck’s feelings known.
The team met its deadline with an acceptable product, though the success was not fully celebrated, largely owing to Chuck’s feelings.
Improving the Process
Especially when there is a relatively informal portfolio and project management process, it is important for all team members to be sensitive to the needs of others as well as to the needs of the project and themselves.
In the case above, the team would have done better to take the time and effort to explain their decision to not engage Chuck in the project. The explanation shows the respect and caring that is fundamental to giving people a sense of belonging. It doesn’t take more than an hour.
The decision to eliminate a voice that might raise uncomfortable questions and alternative solutions is a judgement call by the project manager and the sponsor. While there are exceptions, most often, it is best to at least hear various voices up front before plunging ahead to hit a deadline. Taking the time to document the justification for key decisions avoids problems later on in the project. At the same time, there may be a need for speed.
The trade-offs between the perceived burden of communicating, managing relationships and doing due diligence in decision making, and the benefits of healthy long-term relationships, problem avoidance and optimal product quality should drive the decision makers. Small, isolated teams may very well be more efficient than large, open teams. However, the trade-offs must be assessed before deciding how best to proceed.
While a proactive project manager in a well-established process is responsible for promoting a sense of team membership across all stakeholders, it is also the responsibility of each stakeholder to assess his or her relationship to the team and speak up when feeling left out or feeling that another person is being left out. Chuck could have expressed his feelings and stimulated an explanation of why he was excluded.
Establish guidelines and values. Review projects and the process to continuously improve.
Above all, recognize that everyone has belonging and recognition as needs and be sensitive to how you candidly and sensitively communicate about membership and exclusion decisions.