Easy in theory, difficult in practice

by
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

RSS

Recent Posts

Defeating the multitasking monster

Just because you have information radiators doesn't mean senior stakeholders will review them!

What's the right sprint length for your team?

There can be only one (and it is not YOUR project)!

A camel is a horse designed by a committee

Defeating the multitasking monster

Categories: Agile, Project Management

Multiple research studies have shown the negative impacts of multitasking.

Whether it is the waste generated by context switching, the elevated stress levels for staff or the increased cost of poor quality, few people would assert that it is a good practice for knowledge-based work. Front line workers might argue that their managers think that multitasking works, but I have yet to meet a management team who believe in the practice since most of their members will also suffer from its negative outcomes.

Lots has been written about the benefits of reducing multitasking, but this is not a straightforward feat for most organizations. The Lernaean Hydra (as opposed to the Marvel universe's evil organization) could be used as a metaphor for this unhealthy practice. Deal with one contributing factor and others will take its place.

Here just a few of the forces encouraging multitasking and some suggestions on how to slice and cauterize each one:

  • Using batch-based, push-oriented delivery approaches. When there is finite scope, batched work prevents team members from being kept busy throughout the delivery lifecycle. To avoid idle time, managers are required to assign additional project or operational work. Shifting to a flow-based, pull-oriented delivery approach can increase the likelihood of the full team being busy.
  • A limited capacity of high demand skills. When only a few team members within a delivery organization possess a set of technical or business competencies which are in high demand, managers feel obliged to spread them as thin as possible to help projects or products get some support. There might be insufficient funding to hire more staff with these skills, but a long term solution is to leverage techniques such as non-solo work to build bench strength.
  • Use of inappropriate metrics. Maximizing utilization is easy to do. Set up a time tracking system and track actuals against high targets. Performance incentives (and disincentives) will be based on the level of individual and team utilization. Unfortunately, maximizing utilization is not the same as maximizing the value delivered. Henrik Kniberg does a great job of illustrating this fallacy in this YouTube video. Moving to value-focused metrics should help shift team members and their managers away from just keeping busy.
  • Weak portfolio management. The essence of strategy is saying "No" to the urgent to ensure that the important can be delivered efficiently. Governance committees can start to use criteria such as the cost of delay to determine which investments really must start now and which can be safely postponed.

Similar to battling the Hydra, these ideas need to be considered from a holistic perspective to avoid sub-optimizing the whole.

Reducing multitasking might seem like an impossible feat, but leadership teams should draw inspiration from Heracles.

Posted on: May 19, 2019 07:00 AM | Permalink | Comments (11)

There can be only one (and it is not YOUR project)!

Managing a high priority project can be a wonderful experience.

You will usually receive ample support from senior leadership in resolving critical issues, getting funding for team celebrations is rarely a challenge, and helping team members and other key stakeholders understand the importance of the project and how its success will benefit them should be simple.

But this is rarely the case. Most of the time, we are working on initiatives which, while important, are not top of mind for your senior executives.

Here are just a few of the challenges with managing such projects:

  • Getting and sustaining senior leadership commitment and support is going to be much more difficult. Even your sponsor might have more important projects to support.
  • Keeping your team focused on delivering the project's scope, especially if they are also working on higher priority projects is a constant struggle.
  • Ensuring that functional managers remain responsive to changes in staffing needs and providing you with the "right" staff to get the job done won't be as easy.
  • Securing funding for more than the absolute bare minimum is tricky - especially contingency reserves or budget for team events.

So what can you do to improve your odds of success?

  • Practice effective, full life cycle risk management to reduce the number and impact of unpleasant surprises.
  • Consider using an incremental delivery approach so that your sponsor and other key stakeholders achieve an early and progressive return on their investment.
  • Spend extra effort emphasizing the holy trinity of purpose, autonomy & mastery to inspire your team members to do their best.
  • Double-down on team development through free or low-cost events and simple, but regular recognition of individual and team efforts. Help your team to identify the rituals and working agreements that will define team culture.
  • Have a "Plan B" handy so that if your staffing complement or funding gets slashed the team will still be able to deliver something of value. Wherever possible, structure your scope delivery to deliver higher value work packages early.
  • Take the time early in the life of the project to develop positive working relationships with the functional managers who will provide the staff for your team. Explore opportunities to help them achieve their goals through your project's success. For example, if they want to raise the competency level of their team members, identify stretch activities or other learning opportunities within the project which might address this. If you can earn some IOU's early on with these functional managers, those will come in handy down the road when you'll need their help.

"You should never view your challenges as a disadvantage. Instead, it's important for you to understand that your experience facing and overcoming adversity is actually one of your biggest advantages." - Michelle Obama

 

Posted on: April 28, 2019 10:12 AM | Permalink | Comments (13)

A camel is a horse designed by a committee

Categories: Agile, Project Management

The old saying about committees came to mind when I was considering the default approach companies often use to achieving a control objective. Bringing together diverse perspectives can help to reduce bias, but in many cases a simpler approach might result in a better outcome.

Let's focus on the specific example of a solution architecture review.

It is rare that there is accountability for each member of a committee if their decisions were poor as they have no skin in the game. The power imbalance between the committee and the creator of the architecture proposal being reviewed might also encourage nitpicking over format or style rather than substance.

There is also an increased likelihood of incurring delay and other forms of waste. Committees meet at scheduled intervals which might not align well with the needs of a specific team. The committee might also be faced with a "feast or famine" challenge where they are overwhelmed with submissions at some meetings with the result that certain teams don't get their proposals reviewed. Beyond the proposal review itself, there is usually a need to go through some type of formal intake process and to provide other documentation for committee-specific needs. The overhead costs of running the committee are likely to be charged across all teams.  And don't get me started with the increased costs of re-work or repeat reviews beyond the initial presentation...

So let's consider a simpler alternative as the default approach with a committee used only an exception basis for the most complex situations.

Why not require all architects to spend a fixed percentage of their capacity on conducting structured peer reviews of each other's architectural proposals? Each architect is expected to have a clear understanding of enterprise standards and good architectural practices, so control objectives should still be met.

This addresses both of the previous disadvantages:

  • Greater skin in the game. The architect who reviewed the proposal will be sharing accountability for the outcomes with its creator. On top of that, should the reviewer not be fair in the review process, this behavior will be rewarded in the future when it is his or her turn to be reviewed.
  • Reduced delay and waste as it is much easier for two people to meet than a committee and the level of process or bureaucracy around the review can be minimized.

It might also result in a better architecture as we may be more open to incorporating feedback from one of our peers than a group of seniors.

Ensuring that there is a fair balance of review work across all architects might be achieved through some sort of random allocation system that prioritizes reviewers based on their last review date.

Delivering in a leaner manner should not require sacrificing the control objectives which will keep us safe, it will just require re-thinking how we approach governance.

Posted on: April 21, 2019 07:00 AM | Permalink | Comments (6)

How much technical knowledge should a Product Owner possess?

In an earlier article I'd written about the pros and cons of a Scrum Master or agile lead having deep technical expertise in the solution space but what about a Product Owner (PO)?

In their 2003 book, Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm and Richard Turner coined the well known acronym C.R.A.C.K. to describe the attributes of an effective PO and the K in that acronym stands for Knowledge. Normally, we consider that this is business or product knowledge, but couldn't it also extend to technical acumen?

Technical expertise is likely to help the PO prioritize the product backlog such that there is a healthy balance between business and technical drivers. In the absence of this knowledge, team members might find themselves spending greater effort in helping the PO understand why certain technical work items are time sensitive from either a risk management, dependency or technical debt reduction perspective.

While there is some benefit in a PO having such knowledge, it comes at the cost of greater vigilance. The PO will need to be disciplined to ensure that he or she is maximizing product value by focusing on the "what" and "why" of the product and letting the team own the "how" and "when". Without that mindfulness, such knowledge could result in a PO who:

  • Responds to technical inquiries from stakeholders without confirming the answers with the team
  • Places higher priority on technical work items in the product backlog and neglects the true business needs of stakeholders
  • Turns a blind eye or even encourages technical gold plating
  • Provides the team with system requirements or design guidance thus reducing the team's ability to be creative or innovative
  • Unreasonably challenges the team's sizing of work items or how much they are able to complete within a given amount of time

With great knowledge comes greater responsibility.

Posted on: April 14, 2019 07:00 AM | Permalink | Comments (11)

Proactive dependency management with agile approaches

Categories: Agile, Project Management

When we are managing projects using a predictive delivery approach, dependency identification and tracking is done as part of the BPUF (Big Planning Up Front) exercise using the activities from a work breakdown structure and the collective wisdom of our team members and key stakeholders. If a major scope or solution approach change is identified afterwards, the impacts of addressing new dependencies is usually considered in the analysis of the change request.

But on those projects which follow an adaptive lifecycle, this gets a bit trickier. Given the emergent nature of requirements and design, we are only able to see dependencies to the extent of our team's "headlights" which might just be showing us the next two weeks of work. A team might have "Have all dependencies been identified and captured?" as a guideline within a Definition of Ready (DoR) but that doesn't always mean that it is possible to satisfy that dependency just-in-time.

We always strive to build a whole team which possesses all of the skills and authority needed to deliver the full scope of the product or project.

But sometimes, we need a subject matter expert for a small subset of the product features and if we don't identify that need early enough, we won't be able to deliver those features in a timely manner. In addition, building a whole team in larger organizations is often challenging as there are established delivery or control partner teams who must contribute to specific product features but won't necessarily be available at a moment's notice.

One way to reduce the risks associated with dependencies being identified too late is the combination of upfront story mapping with ongoing look ahead planning.

Story mapping provides an opportunity to bring together key delivery and control partners to review the high-level stories which the Product Owner and team are identifying. Giving these external partners a chance to indicate which stories they are interested in will help the team know who they need to line up as the time approaches to complete one of those stories. Based on how high those stories show up in the story map, they will understand how soon they might need to be engaged. Team members can also start to identify and capture the inter-dependencies between individual stories to help the Product Owner with backlog prioritization.

As stories with dependencies start to move up the backlog, as part of a look ahead planning activity, the team can proactively contact the external partners to request their participation a sprint or two into the future.

Planning is an ongoing activity with adaptive approaches so without this, an external partner your team needs is likely to respond with the old cliche: "A lack of planning on your part does not constitute an emergency on my part."

 

Posted on: April 07, 2019 07:00 AM | Permalink | Comments (10)
ADVERTISEMENTS

"Golf is a good walk spoiled."

- Mark Twain

ADVERTISEMENT

Sponsors