Easy in theory, difficult in practice

The quote attributed to Thomas Edison of “Vision without execution being hallucination” is one side of the coin. As Roger Martin wrote in a 2015 HBR article, execution without vision is mindless.

A good analogy I’ve used to express how tightly integrated the two need to be comes from organized sports.

Head coaches usually have the vision of taking their team to the playoffs or even winning the overall championship. The first failure occurs if that vision can’t be translated into strategies adopted by the management & coaching team including how they will get the right players, how those players will be forged into a cohesive, efficient team and which plays are likely to stymy their opponents. A subsequent failure may happen when they try to execute those initiatives. In either case, the head coach may end up looking for a new gig come the end of the season.

Pre-school soccer presents the opposite problem.

Small children have unlimited energy and lots of enthusiasm, and when they are able to make contact with the ball they can usually deliver a solid kick. Unfortunately, they possess limited attention spans, get easily distracted and require frequent gratification. Their rudimentary execution skills are good, but they are just as likely to kick the ball into their own net as they are to score on their opposition.

While most executives I know would not like the comparison to pre-schoolers, in the absence of an overall vision for a company or division, and without that vision being distilled into strategy, the compass guiding the decisions for those executives usually points to either their own ambitions or their assumptions on what is best for the organization.

Pet projects flourish within such environments.

Here are some of the warning signs which indicate your organization may be suffering from mindless execution.

• Projects increase the level of risk to the organization without delivering commensurate value
• Multiple projects whose goals conflict with one another
• Decision making on transformational projects made by a single executive with little or no collaboration with other leaders
• Significant shifts in scope driven from within, not without
• Team members completing project work without understanding the expected benefits or desired outcomes for the project
• Projects are never cancelled
• The Abilene Paradox best defines your organization’s culture

My favorite expression from the Daleks of the popular television show Doctor Who, is what they’d say when their eye stalk was damaged: “My vision is impaired, I cannot see!“. This was usually followed by the Dalek in question being destroyed. If your company’s vision is impaired it might be your company that is Exterminate-d!

(Note: this article was envisioned and executed in March 2015 on my personal blog, kbondale.wordpress.com)

A lot has been written about the challenges caused by functional managers when their company undergoes an agile transformation. But with this emphasis on what they shouldn't be doing, not as much gets published about the specific activities we should be doing to help them through the change.

Here are four questions to ask when considering this key role.

Are they learning?

To support a change you need to understand the change. Delivering training focused specifically on what functional managers need to know about agile which includes scenario-based learning to understand what sorts of behavior changes are expected when faced with common situations will help. But it is also important to identify which managers have already shown evidence of having embraced an agile mindset and recruit them to help support their peers who will have a harder time with the transition. In the absence of such internal support, coaches could be hired to create a critical mass of change advocates among middle management.

What are they measured on and what are they measuring?

Metrics aren't the sole driver of behavior but they do draw a lot of focus. As Tony Robbins would say, "Where focus goes, energy flows". If we haven't updated performance measures for functional managers and their staff, it will be much harder to encourage them to change. If existing metrics are focused on how well team members and their managers achieved certain objectives but didn't also consider how those objectives were achieved, deadlines and budgets will continue to dominate rather than collaboration and engagement. These measures need to be augmented with ones specifically assessing stakeholder and team member satisfaction to understand whether the "how" was as good as the "what".

Who are they hiring?

I've written previously about the importance of adjusting job descriptions and hiring criteria but it is equally important to train functional managers on how to leverage these changes. If the job profile calls for servant-leadership but all the functional manager asks about is what a candidate accomplished, the risk of hiring people who are not aligned with the new way of working will persist. Pairing functional managers with properly trained HR staff for panel interviews is one way to address this.

How are they supporting their staff?

Team members will be experiencing many of the same fears and doubts that their manager has about the transformation so it is important that functional managers meet regularly in both one-on-one and team settings to address these concerns. Managers play a critical role in helping their staff gain the confidence to take their first baby steps towards self-organizing and becoming T-skilled. To do this, managers must cultivate a psychologically safe environment within their teams so that their team members feel safe about expressing themselves and taking chances both in the project roles and in their functional ones.

Buy-in from middle management is necessary for any successful organization change, and even though you might think that the sandwich approach of committed senior leadership and enthusiastic front line staff squeezing out compliance, actively guiding and supporting functional managers will be essential to a sustainable transformation.

One of the more subtle changes in the Sixth Edition of the PMBOK Guide is the elimination of all references to Critical Chain Method (CCM).

The rationale for this excision was not provided in Appendix X1 of the Guide which provides details of most of the Sixth Edition changes so I can only speculate that this might have resulted from the desire of the volunteer standards committee to cover commonly used tools and techniques for schedule development, and with the addition of agile release planning perhaps CCM became an easy sacrificial lamb.

Many years ago, I worked in an organization where I attempted to introduce CCM as an approach to managing key resource availability challenges as well as shifting leadership focus from individual tasks to milestones.

Unfortunately, this failed miserably.

A fundamental tenet of the methodology is using optimistic activity durations by stripping out padding and by aggregating uncertainty into buffers at the end of activity sequences. I was unable to convince team members to provide such aggressive estimates given the organization’s prevailing culture. Given that a fair bit of padding remained in each activity duration estimate, the buffers ended up being bloated and milestone dates were later than would have been previously planned.

However, some of the key lessons remained with me which I was able to apply later.

1. Eliminate multitasking of high demand, low supply resources. It’s really tempting to squeeze out every iota of working time from such team members, but the opportunity cost of context switching is much greater than for other team members. So while I encourage the elimination of multitasking for all core team members, if that is unrealistic, at least do it for your “drum” resources.
2. Centralize uncertainty into contingency reserves and defend those reserves. Calling these buffers does not resonate well with senior management as the perception is that these will be consumed carelessly. Position them as contingency reserves and they can start to appreciate the necessity of having some shock absorbers to protect the timelines from known-unknowns.
3. Obsess over milestones and not individual tasks. Estimates are probability distributions – some activities are bound to be late and some will be early. A good project manager keeps their eye on the key milestones and while they are aware of the give and take which results from variation in activity end dates, they won’t micro-manage the team to those. This not only reduces perceptions of micromanagement while empowering individual team members, but it also keeps everyone’s eye on hitting the milestone date. Scrum incorporates this principle by focusing team efforts on sprint goals and commitments and not just on individual tasks.

Use of CCM requires a level of scheduling discipline which is absent on many projects and it does lend itself well to deterministic or predictive projects. But just because you can’t use the method as a whole doesn’t mean it doesn’t contain some good practices which could be applied to your project.

(Note: this article was originally written without the benefit of a feeding buffer on kbondale.wordpress.com in October 2017)

During a presentation at a local agile meetup this past week I asked the audience to think about what sorts of projects, products or organizations wouldn't be a good fit for the use of agile or adaptive approaches and one of the attendees felt that regulatory projects weren't suitable.

Non-discretionary compliance projects present many challenges, but does this make them help or hinder their delivery via agile approaches?

Here are some advantages to using adaptive life cycles with such projects.

• The "what" is inflexible, but there is usually wiggle room around the "how". Once external regulations have been translated into a set of internal business requirements there are many ways in which those requirements can be met. With deterministic approaches, a business owner might be tempted to go for a "Cadillac" fully automated solution whereas with an adaptive approach, the focus might be on minimally meeting the requirements through a combination of manual and automated steps and then letting empirical data and budgetary and schedule constraints dictate what incremental enhancements get made.
• Adaptive approaches encourage fixing schedule and cost and letting scope remain variable. With regulatory projects, schedule is usually externally fixed and since there is no business value in going above and beyond the regulatory requirements, a ceiling on costs could also be set.
• Frequent feedback from end users on what is getting delivered increases the likelihood that complex regulatory requirements are correctly understood.
• Early and regular releases will reduce the learning curve for sustaining the process changes.
• Risk exposure can be used as a criterion for prioritizing the backlog of regulatory requirements. With this approach, a regulatory business owner can feel confident that those requirements posing the highest risk exposure to the company get delivered first.

However, there might also be some good reasons to follow a deterministic approach.

• These projects often involve changing multiple legacy processes and systems. Such changes might require heavy governance oversight and there could be blockers such as a lack of automated test capabilities or dedicated environments.
• Regulatory staff are often unable to dedicate themselves to the delivery project given their operational responsibilities so it might be difficult to secure a product owner or other business users.
• Regulatory projects often require participation of external partners such as vendors and government regulators. These stakeholders might be unwilling or incapable of working with an adaptive delivery approach.
• Regulatory business owners might be uncomfortable with not fully reviewing and approving the details of the "how" upfront. While this could be said of any business owner who hasn't previously worked with adaptive delivery approaches, the perceived risks and impact of failure are much higher for regulatory projects.

As usual, when deciding what delivery approach to take, the specific context of the project and supporting organization have to be taken into consideration.

If you have managed a number of projects the following scenario is likely one which you have encountered.  A requirement which was not previously identified emerges after project baselines have been approved, and when you try to follow good project change management practices, your customer informs you that this was not a new requirement but rather one which was missed during the requirements gathering process?

Depending on the approach taken for your project, this may or may not be a big deal.

If you are managing a project using an agile methodology, so long as the requirement does not generate a significant change to architecture, design or delivered value, it is usually just a matter of adding this item to the backlog and then asking the customer to reprioritize the backlog at the end of the current sprint or iteration.

But let’s say that your project was following a waterfall approach or that this recently identified requirement does severely impact foundational work completed on an agile project.  What then?

Referring the customer back to the original requirements baseline is unlikely to provide much comfort.  Even if you are able to prove that there is no way that this requirement could have been feasibly identified earlier in the project’s life, you might be contractually right but are unlikely to get a great customer satisfaction rating.  If this requirement recently emerged due to changes in the environment in which the project operates, even if the customer agrees to leaving things as they are, you could end up achieving the originally approved baselines but not delivering much business value.

On the other hand, if you simply accept the additional requirements, you could end up creating cost, schedule and quality variances as well as losing credibility with your project team and other internal delivery stakeholders.

In such cases, you might be tempted to jump into a time machine (Does Uber supply TARDIS’es?), go back to the early days of the project, and add some clauses to the change management plan which would explicitly spell out what does and doesn’t constitute project change.

Resist this urge (besides, it’s currently impossible!) and avoid conflict through collaboration.

Have your team take the time to do a quick analysis on the impact of the requirement and meet with the customer to review these impacts with them.  Acknowledge the importance of the new requirement to their business, employ active listening to understand whether there are other factors at play which might affect their attitude, and work towards a mutually agreeable solution.  Don’t ignore any options – explore scope trade-offs, alternate resourcing and work sharing.  Make sure the customer fully understands and owns the risk of the change.  In some cases, for the sake of the customer relationship, you might need to dip into your contingency reserves to fund this additional work, whereas in other cases, you may be able to have the customer fund the new work.

Project management is about making the whole more than just the sum of the parts – collaborate to help realize business value while still enabling your delivery team to meet expectations.

(This article was originally published without requirements defects to kbondale.wordpress.com in November 2014)