Process Peeves

Thoughts on simple optimizations that could make daily processes better…

Control partners should have skin in the game!

I finally completed reading Nassim Taleb‘s book Skin in the Game which I had written about in a recent article.

In that piece I had applied his principles when comparing the benefits of a product-centric orientation to the project-centric model which is still found in many organizations. But after finishing the book, I realized that there is a much more compelling example of the challenges experienced with risk asymmetry in many large organizations, namely with those staff who are responsible for developing the policies, standards and methods used by teams for delivering projects or products.

In small companies, how a product gets developed and delivered is usually defined by a “Big Brain” (e.g. a solution owner or similar role) or developed collaboratively by those actually building the solution. But as the size of the organization increases and stakes get higher, control partners emerge to influence not only what but how production occurs.

Where things get difficult is when these control partners do not experience first-hand the downside of their decisions.

For example, in some companies, project management standards are set by a centralized department such as a PMO. While some delivery roles such as program or project managers might report in to the same PMO, there are staff whose sole focus will be to define and maintain standards. As those staff are not in a project delivery role, even if they possess years of practical experience, as they won’t themselves have to use the templates and tools which they have developed, they don’t have true skin in the game. Delivery staff may complain to control partners about how onerous or non-value add specific practices are, but there is little direct impact to them.

There are a couple of ways to rectify this situation:

  • Serving in such control functions could be a rotational responsibility. After someone has spent a reasonable amount of time in a control role, they should be required to spend an equal amount of time in a delivery role. This will also help them better identify patterns and anti-patterns specific to a given context.
  • Introduce performance measures and incentives for control staff which are tied to the impacts created by their work as opposed to just the completion of this work. For example, quantifying the cost of control or conducting regular satisfaction surveys with delivery staff are two methods in which we could bring back skin in the game.

Method makers and framework formulators – practice what you preach!

 

 

 

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

No bugs in agile?!?

When a team is following an agile delivery approach and they have developed a Definition of Done (DoD) containing one or more criteria indicating that no defects are permitted in or as an outcome of completed work items, they should not have to deal with bugs escaping a sprint, and hence, the practice of documenting defects should become obsolete.

But how often does this happen in the real world?

Let’s consider what’s required to achieve this:

  • Pairs programming or other quality-focused development practices
  • Dedicated test environments covering the totality of the solution including all points of integration
  • Full coverage automated regression testing
  • Frequent (if not continuous) integration and deployment to support the progressive testing of completed requirements
  • The planning, definition and automation of test cases covering all of the requirements being worked on in the sprint
  • The ability to execute full non-functional testing within each sprint – security, performance, accessibility and localization to name just a few

If any of the items in the preceding list look daunting in your current context, don’t panic – you are not alone.

Teams in organizations early or midway through agile transformation will work on products possessing none, some or all of the above prerequisites.

In the interim, here are three choices for those teams:

  1. If the defect relates to the natural evolution of the customer’s wants and needs then it should be captured as a new requirement in the product backlog and prioritized by the Product Owner.
  2. If the defect can be resolved and properly re-tested within the current sprint, there is almost no value in documenting it. If there are significant time zone or geographic boundaries separating development and test roles, or if either the developer or tester are unable to work on it right away, the defect might still need to be captured somewhere to ensure it doesn’t fall through the cracks before the end of the current sprint.
  3. If the team’s DoD excludes the resolution of cosmetic or low severity defects, the defect should be added to the product backlog and prioritized by the Product Owner. This is an acceptable compromise for many lower maturity teams, but over time as their delivery capability improves, they will want to tighten up their DoD to prevent a progressive increase in this specific type of technical debt and to avoid their customer experiencing Death by a Thousand (quality) Cuts.

Linus Torvalds said it best “I’m generally a very pragmatic person: that which works, works.

 

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

Why setup virtual PMOs and when should PM templates be standardized?

Dear reader, don’t be alarmed – this IS your regularly scheduled article!

I’d like to thank Sante Vergini for providing the inspiration for the first topic and the second one had been a splinter in my mind so I couldn’t wait till next week to write about it.

Why oh why would someone set up a virtual PMO?

In one of my past articles, I had written about the challenges of establishing and running virtual PMOs. I’m not referring to a PMO which is staffed by geographically distributed team members but rather one which has not been established as a staffed organizational entity. Virtual PMOs might be setup as a single individual spending a portion of their time delivering PMO services or a group of project management practitioners who commit some time to this.

Given that it might be difficult for a virtual entity to elevate organizational PM capability, mature project portfolio management practices or provide a meaningful delivery oversight function, why would organizations choose to go this way?

The most simple use case is when the leadership of a small functional organization-oriented company starts to realize the need to standardize or improve the company’s project management approach. The first person who starts to apply some project management discipline might be drafted into being a PMO of one.

Funding constraints could be another reason to establish a virtual PMO. The majority of PMOs are cost centers and the ROI for the investment in setting up and running a PMO might take a few years. If leadership recognizes the need to do something to improve project outcomes but funding is limited, one approach is to establish a community of PM practice and empower that group to design and implement change on a best effort basis.

Once bitten, twice shy might be another driver. Leadership teams which have lived through the fallout of a failed PMO might try to avoid the sunk costs of Groundhog Day syndrome by going the virtual route. Of course, if they haven’t addressed the root causes for why the original PMO failed, they shouldn’t expect miracles from a virtual approach.

A standard should be the means to a goal and not a goal unto itself

Repeatability is a good guideline when elevating organizational project management capability. But standardizing how information is captured needs to be carefully weighed against the benefits of tailoring and customization.

So what are some criteria which would justify standardizing a specific project management template?

If the information within it is going to be ingested by some automation to feed other processes then standardizing the format will improve processing efficiency and quality. If the consumers of the completed template are working with multiple project teams, there is a benefit in providing them with a consistent look and feel.

But if these conditions are not present, the emphasis should be on the quality of the content and not on the format or structure. If there is still a perceived benefit in standardization, effort should be invested in developing a template which can be easily populated, easily updated and presents what is required by its consumers in a minimally sufficient manner.

Anything more is waste.

 

 

 

Categories: Process Peeves, Project Management, Project Portfolio Management | Tags: , , | 1 Comment

Blog at WordPress.com.

%d bloggers like this: