Project Management

Articles related to doing projects right

Influencing the eternal optimism of a delivery team

When I teach agile fundamentals classes, I frequently emphasize the importance of inspection and adaptation. Teams which don’t use feedback loops with their products and their processes should not consider themselves to be very agile.

For those teams which use an iteration-based cadence for their delivery such as those who have implemented the Scrum framework there have multiple feedback loops to help them improve. A common example is comparing how many product backlog items they were able to successfully complete during an iteration with how many they had forecast that they would be able to complete at the beginning of the iteration.

For stable teams using fixed duration iterations, a reasonable assumption is that over time the volume of work which they can complete should become progressively more predictable which in turn should improve forecasting.

So what happens when a team consistently misses their iteration forecasts by a significant margin?

If it is a team which regularly completes more work than was forecast, this could be the result of traditional management oversight causing team members to act very cautiously when estimating their work. Letting the team know that it is normal that they might miss their iteration forecasts on occasion and spending effort on making the team feel safe might help them to start making more aggressive forecasts over time.

But what about the team who is frequently completing a lot less than they had forecast?

It would be very easy to write off such teams as undisciplined or immature but such judgments won’t help the situation.

There could be many factors causing the team to fall short including:

  • Underestimating work item effort or complexity
  • Insufficient dependency identification
  • Poor risk management
  • A lack of focus caused by multitasking or other sources of distraction

A retrospective provides a safe place to identify the situation and to come up with improvement suggestions which the team can take into their next planning session.

This might also provide a good opportunity for the product owner to express some sadness that the team wasn’t able to meet their forecast and to help them understand how this could reduce their credibility in the eyes of key stakeholders.

Regardless of the cause, understanding why the team is over-forecasting is an important step as that information can then be used to create a sense of urgency regarding this behavior.

 

 

 

 

Advertisements
Categories: Agile, Project Management | Tags: | Leave a comment

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

 

 

 

 

Categories: Project Management | Tags: , , , | Leave a comment

A camel is a horse designed by a committee

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.

 

Categories: Agile, Facilitating Organization Change, Process Peeves, Project Management | Tags: , , , | Leave a comment

Create a free website or blog at WordPress.com.

%d bloggers like this: