Easy in theory, difficult in practice

Recently, I've been experiencing frequent brief loss of Internet connectivity issues at home. I live in a major urban area, no internal or external home renovations have happened which would affect cabling, and my cable modem was recently swapped. Thankfully, the technician who swapped the modem did provide me with his mobile number and recommended that I call him if I had further issues within a few weeks.

We have all heard that the Internet is becoming a critical utility and hence we should demand the same reliability as we do with power, water or our telephone dial tone. While this is a reasonable expectation, few Internet Service Providers (ISPs) have focused on this in their marketing campaigns to the personal market. Commercial customers are a different story - they enjoy real SLAs but at a higher cost. Most of the ISPs who service residential customers will hype their transmission speed or capacity in their advertising. While those are important, guaranteed up time would be a more welcome benefit in the long run, and would likely contribute to greater customer loyalty. ISPs are under pressure to scale their infrastructure to support greater speeds at lower costs, but the side effect of this "arms race" might be reliability.

This situation brought to mind the challenges we face when communicating delivery metrics as part of an agile transformation.

Many of the leaders I've worked with focus on schedule metrics: reducing time to market, lead time, time between releases, and so on. While these are important, an overemphasis on reducing lead time may unconsciously encourage delivery teams to kick quality concerns down the road. Having effective Definition of Done working agreements can help, but these can also be diluted to favor speed over quality. Defect reporting and customer satisfaction surveys provide opportunities to identify whether there is an unhealthy focus on delivering faster, but these are lagging indicators.

This is why it is so important that the communication campaign supporting the transformation, including the sound bites from top-level executives, reflect an equal footing for speed AND quality. And mid-level managers need to walk this talk in their daily interactions with their teams.

Don't sacrifice quality at the altar of speed.

For those of us who have worked most of our careers in companies with functional or matrix power structures, project-oriented organizations can appear very attractive in comparison.

This is understandable given the many challenges project managers can face when their roles are poorly defined or when they have no little authority over team members or decision making. I can recall countless cases of project managers escalating concerns over individual team member behavior to people managers only to be told that perhaps the project managers themselves are the problem.

Support for project managers can also be limited.

If they are lucky, they might report into a PMO which provides professional development opportunities and they can benefit from the support of their peers but unless the company is at a higher level of organizational project management maturity, the role of the project manager might still be a thankless one at times.

In a project-oriented company, the role of the project manager is well defined, they usually possess formal authority (including hiring and firing power) over their team members, and they are likely to have greater decision making authority than in matrix or functional organizations.

Seems like Nirvana, right? Unfortunately, formal authority is not all it’s cracked up to be.

Just because you have the ability to directly impact someone’s performance evaluation, annual bonus or even their job, doesn’t mean that will automatically motivate them to give you their best efforts. Possessing formal authority over team members can be a curse – you have to work twice as hard to capture the hearts and minds of your team members through vision, influence and persuasion as it is all too easy to fall into the habit of saying “It’s my way or the highway!”.  In functional or matrix organizations, that approach isn’t even possible, but in project-oriented organizations, team members will listen because they fear the consequences of not doing so, but you will get their support at the cost of true engagement and commitment.

In project-oriented organizations, the project manager can also bear the brunt of negative project outcomes. They possess the authority, but with that comes the risk that if the project fails or the customer is unhappy, they are more likely to be impacted than in a functional or matrix organization where decision making authority and accountability is diffused.

Finally, what happens when your project ends and there is no more work? Project managers in functional or matrix organizations might lose their jobs if they are unable to find a lateral role. In a project-oriented organization, lack of new projects could mean that not only the project manager, but their team members could also be negatively impacted, and the project managers will have to bear the resulting emotional stress.

Can project-oriented organizations be better than functional or matrix ones? They can, but caveat emptor!

(Note: this functional article was originally published on kbondale.wordpress.com in February 2015)

Many of the companies I’ve worked with have invested significant effort in developing and implementing consistent project intake processes, often supported by fairly costly project portfolio management systems.

While these changes can reduce the occurrence of pet projects, they still won’t make a meaningful difference in portfolio value realization. Yes, increased effort may be spent in creating business cases than before and those business cases may get challenged by different levels of governance committees, but that doesn’t mean benefits will be realized as expected. Unless the requested funding is tremendous, the level of scrutiny the business case will experience is likely to be restricted to a quick review of assumptions, validation of SWOT analysis and other such sanity checks. To really validate the realism of the benefits model would require an investment of a similar (if not greater) level of effort which was spent on creating the original business case.

Most sponsors tend to display a strong optimism bias – if they didn’t, they’d be unlikely to sponsor transformational projects. However, this optimism bias can result in inflated expected benefits and the underestimation of the one-time or ongoing costs or the impact of external factors which could reduce benefits.

Without some sort of benefits management framework that insists on objective representation of expected benefits when baselines are committed and then regularly re-checks the likelihood of realizing those benefits, risky project investment decisions could still be made. And once a project is over, even if no benefits were realized, few organizations will hold the sponsor accountable for poor outcomes. While chronic offenders likely deserve some punitive action, I’m not a fan of tying compensation to benefits realization – while that creates “skin in the game”, it also might generate an overly conservative culture which could result in competitive disadvantage for a company.

This made me think about credit ratings – independently established metrics providing an objective method of evaluating the credit risk of an individual, organization or country. Could this approach not be adapted for assessing the benefits realization reliability of a given sponsor?

Similar to a credit rating, new sponsors would start out with a modest reliability rating. As they request project investment decisions and the benefits are realized (or not), their rating would increase or decrease. These ratings could then be used as an input into project intake reviews. Sponsors with good reliability ratings would be subjected to less scrutiny and have access to higher levels of project funding. Those with lower reliability ratings would have their business cases challenged more rigorously and could have more funding disbursement gates.

So who would calculate and publish such reliability ratings? This could be a job for your friendly, neighborhood PMO.

(Note: I checked the credit rating of this article when it was originally published in March 2015 on my personal blog, kbondale.wordpress.com)

Project management practices have been used since human beings first started to work together to achieve greater outcomes than they could have accomplished as individuals. Modern practice of the profession started in the 1950's so it is natural that certain practices, tools and nomenclature will be discarded as the profession evolves.

Unfortunately, some anachronistic project management terms still linger in spite of overwhelming evidence that their time has passed.

Waterfall & Traditional

Waterfalls usually provide a one-way journey for those unlucky enough to take a ride over them. Even the most deterministic lifecycle will provide some instances (no matter how small) of iterating back. Traditional is a subjective term. The Manifesto for Agile Software Development was signed in 2001 and before its arrival launched agile into the mainstream, adaptive lifecycles had been used for many years. Traditional could be equally applied to deterministic and adaptive lifecycles when we consider that many new project managers were born around Y2K!

Resources (when referring to people)

The PMBOK's Project Resource Management knowledge area might cover the management of both people and materials, but calling our team members "resources" encourages poor management practices by equating them to commodities and furthers the myth and resulting risks of fungibility. There are many positive synonyms which can be used to reference the people on our teams including their names(!), "talent", "contributors" and "performers" so there's no reason to use such a divisive term.

Best practices

I applaud the efforts of the PMBOK Guide, Sixth Edition volunteer team in adding the Tailoring Considerations section to each knowledge area chapter but this is just the first step in a long journey of providing guidance for adapting project management practices and tools to the context of a specific project and organizational culture. Certain other professions might have standard procedures which are appropriate in all circumstances (e.g. turn the power off before working on an electrical circuit) but while the principles of project management are universally applicable, specific practices or tools are not.

The practice of trepanation was used in ancient times as a cure for the evil spirits possessing sick people's heads. However, if a doctor was to approach your head with a drill, in all except the most extreme circumstances, you would be forgiven for running away! If we wish to demonstrate the evolution of the project management profession, similar Spring cleaning is needed with our lexicon.

“It’s the question that drives us, Neo. It’s the question that brought you here. You know the question, just as I did.” 

No, it’s not “What is the Matrix?” but rather, how do you know when your team has done enough project planning to feel confident that commitments can be made to your customer?

Isn’t there an app for that?

Wouldn’t it be wonderful if there was the equivalent of a meat thermometer that could let you know if further planning is required or if you are at risk of realizing business value shoe leather?

There is no expert system which codifies the shared knowledge of the world’s project management experts to help you know when enough is enough. The essence of projects is uncertainty, and it is that uncertainty which stymies the best efforts of project teams to find the sweet spot.

While we may not be able to perfectly time it, here are a few tell-tale signs which could tell you that it’s either too soon or that you may have gone too far.

When should you put your project plan back in the oven to bake some more?

• When more than just your risk averse team members are expressing concerns
• When you are not sure that you have identified and assessed needs and wants of all key stakeholders
• When there are still some shaky assumptions supporting the foundation of your plan
• When a second (or third) pair of fresh eyes hasn’t reviewed key elements of the plan
• When resource estimates are based on the work being done by very specific individuals and their availability is still questionable
• When each day brings new information resulting in meaningful shifts to approach or estimates

When is your project at risk of getting burnt from too much planning?

• When team members are dwelling on details of activities which are in the distant future
• When only your risk averse team members are feeling concerned that it’s still not quite ready
• When a variety of different techniques support the estimates where commitments are going to be made
• Once response plans have been successfully implemented for all key risks
• Once commitments are in place for all key resources
• When the number of new revelations impacting estimates is few and far between

Professional chefs are able to use a dash of this or a splash of that while novice cooks must practice strict adherence to recipes. With experience, our intuition for knowing when we are ready to get started improves. However, introduce sufficient change into the scope or context for a project and even seasoned project managers will need to fall back on signs such as these.

(Note: I baked this article in February 2015 on my personal blog, kbondale.wordpress.com)