Easy in theory, difficult in practice

My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

Need help team building? Try to escape an escape room!

Execution without vision is like pre-school soccer!

Helping functional managers through an agile transformation

In defense of Critical Chain

Are regulatory projects a better fit for adaptive or deterministic delivery approaches?

Helping functional managers through an agile transformation

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.

Posted on: September 16, 2018 06:59 AM | Permalink | Comments (13)

Are we marketing the right metrics?

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.

Posted on: September 02, 2018 06:59 AM | Permalink | Comments (12)

Responding to change shouldn't mean teams face continuous change!

The fourth and final statement in the Manifesto for Agile Software Development states that we should value responding to change over following a plan.

The purpose behind this preference is to ensure that while a plan might be created to guide team efforts, there should be openness from the team, product owner and key stakeholders to encourage and incorporate changes which will deliver greater business value for our customers.

But as with everything, moderation is key as on more than one occasion I have seen team members experiencing virtual whiplash from a high frequency of significant requirement changes.

Teams will become more change resilient as they mature but there is a natural limit to the volume of changes that any team can absorb.

Think of Morpheus fighting Agent Smith in The Matrix. Morpheus is an accomplished martial artist and has full confidence in his abilities to hold his own, but at a particular point in their fight the frequency of Agent Smith's punches is simply too fast for Morpheus to block.

The team remains busy completing work items but it feels like a random walk to nowhere and morale will suffer as they see that they are regularly taking one step forward and two or more steps back.

Even though the eleventh principle in the Manifesto states that the best architectures, requirements, and designs emerge from self-organizing teams, it is impossible to create a quality architecture or design which is capable of incorporating frequent, major shifts in direction. Frequent major changes will also encourage short term thinking by the team which could cause an increase in the level of technical debt.

This is why it is crucial to create genuine shared understanding and buy-in to a product or project vision upfront and then to translate that vision into a product road map or, better still, a story map. Significant changes to these artifacts should be managed through a lean but disciplined review process which might include temporarily halting the team's efforts until the impacts of such changes can be properly assessed and incorporated.

The Greek philosopher Heraclitus might have said that "The only thing that is constant is change" but that doesn't mean we should expect constant change!

Posted on: July 08, 2018 10:32 AM | Permalink | Comments (14)

Impacts of traditional project funding models on agile delivery

In one of my previous articles I'd written about the need for change across multiple areas of an organization when undertaking an agile transformation. A key enterprise partner is the Finance department and the organization's model for project funding will have significant influence over successful agile delivery.

Traditional project funding models are anchored to periodic (annual, semi-annual or quarterly) portfolio re-planning exercises which ingest updated forecasts for active investments and funding requests for new ones. The funding approach for an investment might be one time lump sum, split into two pieces (e.g. seed and remaining), or progressive through the use of funding tranches.

The challenge with all of these funding approaches is that they are based on an estimated cost of a project rather than the funding we wish to allocate to a product, capability or service.

So what challenges arise from a project-centric funding model?

It can result in higher risk, premature financial commitments.

Even in those cases where a funding tranche approach is used, the expectation is that the estimate for the current funding request will be at a high level of confidence. Now nothing prevents project teams from requesting a minimal amount of funding (e.g. one sprint's worth), but in most cases, project funding approval processes are not lean enough to encourage such behavior. Given this, teams choose to make a funding commitment tied to a major milestone such as a release which might span multiple sprints worth of work. The danger in this is that unless we have a long lived team with predictable velocity working on a well understood product, the level of confidence in the work to be done and how complex that work is will drop the further out we go resulting in a team being at risk of a cost overrun.

Now you might say that agile delivery approaches can work when we fix cost and time and let scope or requirements be the variable. This is true, but how do we know how much to budget up-front to be confident in meeting business needs?

It can also encourage sloppy product management.

When product owners receive funding for a single project and don't have any guarantees that they will receive funding for follow-on work, it is tempting to throw everything and the kitchen sink into the project backlog and to procrastinate on making tough prioritization decisions. With product-centric funding, the product owner can effectively prioritize the product backlog with confidence that there is available funding for incremental evolution of the product's capabilities.

Moving from a project-based to a product-based funding model is a challenging people, process & technology change, but will be a powerful accelerator for your agile transformation.

Posted on: June 16, 2018 07:00 AM | Permalink | Comments (14)

Are you missing a musketeer on your projects?

Ask someone which delivery roles are critical to successfully completing a project and you will get a wide range of recommendations. Three of the more common roles likely to be stated include a project lead, a requirements lead and a solution lead. This is logical as the first is responsible for the delivery process, the second what needs to be delivered and the third how it will be delivered.

But aren’t we missing a vital role on most projects?

Sponsors are funding our projects to realize expected business outcomes and these outcomes are achieved through successful change implementation and not just by completing project deliverables.

Your core delivery team should be the Four Musketeers instead of the Three Amigos through the addition of a change lead.

On small, low complexity projects, a person fulfilling the project lead or requirements lead role might be able to wear more than one hat and take on a change lead role but the same reasons apply for not doing this on larger, more complex projects as would for combining the project lead and solution lead roles.

It’s a question of both capacity and capability.

The more complex a project, the greater the likelihood of the project or requirements lead focusing on the current stage and progress of the project and its deliverables rather than planning and preparing for successful change adoption and sustainment. While they will be actively engaging with stakeholders, the conversation might not stray into post-project topics. While good project and requirements leads are expected to possess advanced soft skills, the emphasis on specific soft skills required to be a successful change lead will vary from those for the other roles.

Looking beyond delivery risk a change lead has the ability to elevate the visibility of execution and operational risks caused by or impacting a project. One example of these is change storms which result when multiple projects and operational events impact a specific stakeholder community within a short period of time.

Change leads are more than just a nice-to-have role on most projects, yet are often ignored or eliminated through a myopic focus on cost containment.

You get what you pay for.

(Note: this article was originally written by me in December 2016 on my personal blog, kbondale.wordpress.com)

Posted on: June 13, 2018 07:00 AM | Permalink | Comments (9)

"I'm not saying anything. There is no message."

- John Lennon