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

What are some of the underlying causes of ineffective project risk management?

PMI plus Disciplined Agile might be a marriage made in Heaven

How open are YOU to changing your launch plans?

Does closeout vary between projects following an adaptive rather than a predictive life cycle?

Our stories aren't getting done!

What are some of the underlying causes of ineffective project risk management?

Since I first started to learn about project management, risk management has always fascinated me.

That characteristic of uniqueness which separates operations from project work introduces uncertainties which, in turn, generate risks. Most mega-project case studies give credit to an effective risk management approach as a key contributor towards their success. But in spite of this, risk management continues to be one of the weakest practiced knowledge areas in the PMBOK.

If eternal optimism is the prevailing mindset within a company, it can be difficult for risk owners to envision things not going according to plan. What has always intrigued me is how the same leadership teams which can be moderately effective at implementing operations or business risk capabilities will be so much weaker when it comes to project risk management.  A risk averse culture will take a long time to change for an overall organization, but a project manager should be able to influence it within the ecosystem of their projects.

Unhealthy levels of multitasking by project teams and stakeholders result in those practices perceived as unnecessary being jettisoned or being given lip service only. If a team barely has time to deliver the scope of their project, how can they or equally busy risk owners be expected to expend any real efforts on considering or responding to potentialities which may never be realized? And, if we combine this limited availability with "one size fits all" approaches to project risk management, it is no wonder that many teams will do the absolute bare minimum required to meet onerous governance requirements.

If team members and other stakeholders don't know what effective project risk management looks like, how can they be expected to improve? If there are no coaches to help teams improve their capabilities, improvements in risk management will rarely happen organically. Competent risk management requires exceptional interpersonal skills in addition to some basic technical skills, so hands-on practice with feedback from seasoned practitioners is needed to improve.

Finally, there might not be a realization of the positive correlation between effective risk management and successful project outcomes. In the absence of supporting internal empirical data or strong pressure from the outside to create a valid sense of urgency, senior leaders and project teams will be unwilling to sustainably invest in the required behavior and practice changes.

Providing practitioners with risk management training or evolving project delivery standards might help in some small way, but real improvements will only come when these root causes are addressed.

Posted on: September 15, 2019 10:50 AM | Permalink | Comments (5)

What's the right sprint length for your team?

Categories: Agile, Risk Management

The Scrum Guide calls sprints the "heart of Scrum" and also indicates that they should be one month or less. The Guide also cautions about setting sprint durations longer than a calendar month to ensure that inspection and adaption is happening frequently which will reduce the risk of wasted team effort or of building the wrong product. This aligns with the third principle from the Agile Manifesto which encourages teams to deliver value frequently, from a couple of weeks to a couple of months.

A research survey conducted by Scott Ambler+Associates found that the most common duration used by teams following a sprint-based delivery model is two weeks, but how should a team decide what is the optimal sprint length for them?

Their decision should consider a number of factors including:

  • How "new" the team is
  • Their delivery process
  • Constraints on their being able to complete product backlog items
  • The maturity or capability of the team to disaggregate work items to a small enough size so that they can complete multiple items in a sprint
  • Expectations from the stakeholders who will participate in sprint reviews

For teams which have just formed or are working with technologies or a product which is new to them, too short a sprint duration may prevent them from being able to complete anything meaningful. This could cause them to get discouraged and might frustrate the stakeholders who are expecting to see progress every sprint. On the other hand, if the team is new to flow-based delivery approaches and they start with a long sprint duration, they could revert to traditional behaviors where they complete batches of work items in phases over the life of the sprint.

When in doubt, it is usually better for a team to choose a shorter sprint duration as this should encourage them to identify, elevate and eliminate the real constraints which limit their ability to deliver. With the longer duration, while they might be aware of the constraints, their sense of urgency may be less.

The team should not change sprint lengths on an ad hoc basis, but if they have identified triggers which suggest that they need to increase or decrease duration then such changes might be done after a major product release. Improvements in the team's productivity or a high degree of volatility in the product backlog are two possible triggers. Another example is if the stakeholders attending sprint reviews consistently feel overwhelmed with the content of the product increment being demonstrated to them.

Sprint duration is another case of Goldilocks and the three bears - finding out what's "just right" will take some trial and error!

Posted on: May 05, 2019 07:00 AM | Permalink | Comments (8)

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)

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)

Don’t get blindsided by stakeholder influence

I’ve written a few articles on the risk posed by resource availability to most knowledge-based projects, and I still feel that this is a frequent cause of schedule & budget overruns.  Other common risk factors impacting projects include requirements clarity, technology uncertainties and organization change resistance.  Finally, project priority is a major source of risk these days – the “star” project that receives funding and focus today could morph into the “dog” tomorrow that is starved of resources.

A more subtle risk factor, and yet one that can be equally pernicious has to do with that unique project role – the stakeholder.  I was once told this definition for a stakeholder: “Anyone with the ability to sink your project”.

One tends to think of negative stakeholder influence as a common source of risk to construction or other highly visible external projects, but any moderately complex internal project could also possess multiple stakeholders with competing agendas.

To address this source of risk, the best response is thorough and regular stakeholder analysis.  If you are not sure that you have identified all of your stakeholders, seek advice from a peer or mentor.  Meet individually with your stakeholder representatives early on and reinforce these relationships throughout the lifecycle of your project.  It may be naive to assume that you can satisfy the needs of all of your stakeholders, so your objective should be to manage the impacts of their influence on your project.  If it is not possible to work towards a “win, win” situation, you may need to solicit assistance from your project sponsorship or other stakeholders.

Project teams working on high stress, aggressive time line (is there any other kind?) projects tend to focus on their customer or  their project steering committees.  This myopia can be fatal – stakeholder influence is perhaps the best example of Dr. Hillson’s definition for risk: “Uncertainty that matters”.

(Note: I wasn't blindsided when I wrote this article in January 2011 on kbondale.wordpress.com)

Posted on: March 14, 2019 08:51 AM | Permalink | Comments (9)
ADVERTISEMENTS

The second day of a diet is always easier than the first. By the second day you're off it.

- Jackie Gleason

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events