Easy in theory, difficult in practice

In the project management world, being a vigilante is rarely advisable. Managing a project without proper authorization is not keeping Gotham or your company safe. And the Commissioner Gordon of your organization is more likely to put you in Arkham Asylum than congratulate you for showing initiative.

So what prompted this week's Dark Knight analogy?

I recently taught a project management foundations course in which I spent some time talking about the importance of having a project charter.

I asked my learners to recall one of the old Western films they might have seen where an unnamed drifter (usually played by Clint Eastwood or a similar actor) rides into a town which is clearly in need of some law and order. The drifter makes quick work of a couple of baddies in the local tavern but happens to attract the attention of the town's sheriff. The sheriff is aware of his own ineffectiveness and convinces the drifter to clean the town up. And to make it official, the sheriff pins a deputy badge on the chest of the drifter.

And that's what a project charter does for us.

It could also provide a whole slew of other benefits including:

• Providing stakeholders with a high level understanding of the why, what, when, and how
• Helping to resolve any "grey areas" before we proceed further
• Identifying some of the key stakeholders and their roles (e.g. sponsor, PM)

But it's primary value is to formally authorize the existence of our project. Without it, we are consuming the organization's resources towards a well intentioned goal, but without evidence of any approvals for this work.

In the case of projects done for or with third-parties, a contract might be in place before a project starts. In such cases, the contract serves as a charter if a separate one isn't created.

However, on projects which don't involve contracts such as those done wholly within a company, are charters still used?

I decided to pose that question to the members of PMI's LinkedIn Project, Program and Portfolio Management discussion group. I gave them three choices to choose from for how their company's internal projects are authorized:

• A verbal request from a leader
• An e-mail request from a leader
• A written, formal document

My expectation was that the third choice would win nearly all of the votes. While it did receive just over two thirds of the seventy votes cast, 13% indicated a verbal request was used, and 19% responded that an e-mail request was provided.

An e-mail message might not be sufficient to satisfy some of the other benefits of having a charter but it does at least provide evidence of approval as long as it describes the work to be done and is issued by an appropriate authority figure.

A verbal request on the other hand is worth the paper it was written on.

So the next time someone asks whether you are a project management Batman, the only correct answer is "No!".

A question which I'm asked regularly during my classes is what the best place is to start an agile transformation within a company? Given a choice, I'd prefer to use the cop-out (but correct) answer "It depends", but otherwise I usually respond that you'd want to do both a top-down and bottom-up approach simultaneously.

A common approach for major organizational changes is to start at the top with executive leadership, creating a coalition of commitment and support towards a shared vision for the future. This is critical with agile transformations for a number of reasons:

• Delivery teams don't work in isolation and hence buy-in to change how things are done will be needed from all supporting areas including human resources, finance and procurement.
• There will be the need for funding investments such as training, coaching, tooling and potentially even staffing new positions.
• Without changing existing portfolio intake practices and performance measures (e.g. shifting from a focus from maximizing utilization to maximizing value), it will be hard to achieve the full benefits of the transformation.
• To shift the established behaviors of middle management towards an agile mindset, the executive team needs to model the desired target behaviors first. Not only will the executives need to be coached to get there, they must also agree to hold each other visibly accountable to this new way of working.
• There needs to be a unifying vision for the transformation as well as a roadmap for how to get there. The executive team must be fully engaged in the creation of these key deliverables.

But there will also be the need to have engagement at the delivery team level. If individual team members are comfortable with how things are working and have no sense of urgency about the need for change, then their support will be superficial. Their buy-in is needed to:

• Develop the details of the new ways of working and inspect and adapt those over time.
• Feel comfortable designing and conducting experiments and having the occasional setback with those.
• Be willing to take on new roles and responsibilities.
• Be open to providing stakeholders with a greater level of transparency into their work and work flow than they have been used to.
• Collaborate openly with contributors from other functional areas whom they previously might have just cooperated with.

While these outcomes are needed, a key benefit of taking this top-down & bottom-up approach is that it will create a "sandwich effect" squeezing those middle managers who are unwilling to change how they work. Without that outcome, it is unlikely that an agile transformation will succeed.

I was asked a very unique question by one of the learners in a project management course I taught this week: "How do I motivate my team members when even I don't believe in the project?".

While I'd been posed this question for the first time, it is not an uncommon challenge. It is hard enough for project managers who are in full support of their projects to inspire disengaged team members so having to do so when the project managers themselves don't feel the projects are worth doing is much worse.

Start by confirming the issue does not rest with you. Are you experiencing some general malaise with the company, your role, or some other personal cause which has nothing to do with the project? If so, deal with that first, or recuse yourself if you have the option to do so until you can deal with your personal issues.

Assuming the challenge is with the project and not you, how do you go about addressing this?

You can't just grin and bear it. If you don't really believe in the benefits from the project, it will be hard for you to create a genuine sense of purpose for your team members. Worse, if you try to fake it, your team members will pick up on this and you will lose credibility with them which will hurt you much more if you have to work with them on future projects.

Make sure you understand the underlying business rationale for the project. Whether there is a financial motive or not to the project's existence, is there something you are missing with regards to its expected benefits? If you have a good relationship with sponsoring stakeholders, meet with them to ensure you have the full picture. Ask your peers if they can see something which you don't.

If it is a non-discretionary project, ask yourself why you don't believe it needs to be done? We always want to lead disruptive, innovative, sexy projects but just because you are working on a mandatory project doesn't mean that your team members can't express their creativity, especially in coming up with lean solutions to the minimal requirements. With such projects it is often a question of re-framing how you perceive them. By keeping your organization safe, you are improving its brand, reducing risk and opportunity costs.

What if it is a discretionary project? Even if it is not improving profitability or solving world hunger, is there any benefit which justifies the investment? Even if the answer is "no", could there be an intangible reason for it such as a promise made to a critical stakeholder which, if broken, would cost a lot more to address in the future? If so, why wouldn't you want to support it?

But sometimes the project you are leading truly has no merit. If so, this is the time to use your powers of influence and persuasion to convince the sponsor, governance committees and other decision makers to do the right thing. And if they don't, you have a tough personal decision to make.

If you are asked to lead a project and don't want to, always start with why.

COVID-19 is like that car accident just up ahead which you know you shouldn't be focusing on while driving, but which draws the attention of all around it. After doing a number of articles related to the pandemic, I'd planned to write about something completely different, but as my weekly blogging time drew near I realized that there was (at least) one more topic I needed to write about.

I've often said that one of the bigger challenges with agile transformations is the costs of doing nothing (different) today is cheaper than those of changing things so that they will be much better a year or two down the line. This is especially true when you look at companies which operate in markets which are near monopolies or oligopolies as they might still succeed in spite of themselves. Implementing transformations such companies can be orders of magnitude more difficult than in those companies who need to always be more efficient and effective than their competitors in order to survive.

But all that has changed.

Operating budgets have been slashed, companies have frozen hiring, supply chains are under such heavy demand that materials may be unavailable when needed and staff availability is even more unpredictable. Regulations are being introduced at lightning speed, fast-tracking public policy changes in hours or days which normally would take months to push through.

And worse, don't expect a quick resolution.

Under such conditions, it is not enough to just deliver business value from your projects as early and regularly as possible, avoiding non-value add efforts and inspecting and adapting based on changes within and without.

Portfolio investment decisions will also need to be made in a similar manner. Funding plans might need to focus on shorter time horizons and provide Plan B (and C and D) options of what could be delivered with progressively greater constraints on investment.

Defining right-sized MVPs, MBIs and MMRs will be critical.

Product and solution viability risks will have to be explored much earlier than they might have been previously.

Understanding our cross-functional value streams and finding ways to reduce the cost of delay across them will be that much more critical.

And teams will have to take an enterprise-level view, making sure they are engaging delivery and control stakeholders appropriately so that business and control objectives are both being met.

And above all, we need to double-down on putting people first. 

PMI just released the Benefits Realization Management practice guide this month which provides comprehensive but still easily consumable coverage of a benefits management framework covering principles, practices and roles. There is no doubt that benefits management is a critical competency for any company whether they are for profit or not-for-profit but it is also not well  implemented in many organizations.

Overly optimistic business cases might be one reason for this as I'd covered in an earlier article, but there are other potential causes including:

• An unwillingness to hold sponsors accountable for expected benefits. While punitive measures may create a culture of fear and drive otherwise effective sponsors away but there still needs to be some way of ensuring that sufficient due diligence has gone into identifying benefits. Independent verification of benefits analysis is one way to reduce inflated expected outcomes without scaring off potential sponsors.
• A lack of objective definition of the benefits expected to be realized when executing a given investment. Even for initiatives with a financial benefits motive, it may be difficult to demonstrate causality between the outputs of the project and expected financial outcomes as there will usually be more multiple projects with the same types of measures (e.g. increase revenue, reduce costs).
• Limited monitoring of expected benefits over the life of an investment. Projected benefits like scope, schedule and cost baselines represent what is expected at the point in time when they were defined so ongoing forecasting is crucial. Without this, delivery might be successful within approved scope, schedule and cost constraints, but the project's ROI is never realized. Sometimes there is no owner identified for tracking benefits during the life of the project while other times an owner has been anointed but is ineffective in that role or is unwilling to declare that the project won't deliver expected benefits proactively.
• Benefits realization timelines are excessively long. The more time which passes between the end of a project and when expected benefits should materialize, the more fragile those benefits will be due to the impacts of internal and external changes.
• Poor project delivery. While the outcomes of a given project may not change, if the costs or timeline for realizing those increase significantly due to delivery issues, the project's ROI will be worse than expected.

For leaders looking to improve benefit realization from their project investments, doing some root cause analysis to identify why projects aren't generating expected benefits can help them to focus their improvement efforts.

Mohamed El-Erian - "Investors have to ask themselves two questions. How much can we grow our investments? And, can we afford our mistakes?"