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

Are you just following up or are you micromanaging?

Essentialism is agile

Reduce risk by enhancing estimation

Because "It's there" is not a good reason to pursue agility!

Risk Management is not an island!

Are you just following up or are you micromanaging?

This Dilbert comic strip provides us with a good reminder of the fine line which exists between reasonable oversight of activities and micromanagement. Dilbert has allowed sufficient time to pass before seeking an update on a colleague’s assigned task only to find that it has been neglected due to a lack of following up. When Dilbert attempts to get commitment on a revised completion date, he’s accused of micromanaging the activity.

What is deemed a reasonable amount of oversight by a manager may be perceived as micromanagement by team members.

While some teams might possess sufficient psychological safety to embolden team members to voice their concerns, the culture within other organizations or teams might actively discourage this sort of straight talk. In such environments, the frustration felt by the team members festers resulting in impacts to their productivity and slowly poisoning team morale.

And this can become a vicious cycle as team members become progressively more disinclined to share updates with their leaders which results in even greater degrees of oversight.

So how can we avoid this?

It has to start with the leaders and team members collaboratively developing work management practices. If these practices get imposed by leaders or solely developed by team members they will never satisfy the needs of both parties. Early in the life of a project if the objectives for both sets of stakeholders are put on the table and an honest, frank discussion is held about principles governing how those objectives can be met, a set of practices which both sides buy into can be developed.

It also helps to make the oversight process as seamless as possible. Use of visual work support tools such as physical or online Kanban boards can shift the model from assigning work to team members to team members signing up to complete specific work items while simultaneously providing transparency into what’s done and what’s left to be done.

Finally, reducing cross-initiative multitasking can enable staff to complete tasks quicker and with higher quality while eliminating the need for managers to have to constantly follow up with team members to ensure that priorities haven’t shifted.

Micromanagement is like Justice Potter Stewart’s famous description of the threshold test for obscenity : “I know it when I see it”. Given this subjectivity, it’s better to avoid getting being accused of it to begin with.

(Note: this article was published without micromanagement in March 2017 on kbondale.wordpress.com)

Posted on: October 17, 2018 08:47 AM | Permalink | Comments (2)

Essentialism is agile

Categories: Agile, Project Management

I'm reading Greg McKeown's book Essentialism: The Disciplined Pursuit of Less and many of the lessons within it echo the tenth principle from the Manifesto for Agile Software Development which is "Simplicity--the art of maximizing the amount of work not done--is essential".

In the past, I've mostly considered this principle as it relates to how we deliver value to our customers. It provides a constant reminder that practices, ceremonies, tools and artifacts are just a means to an end, and shouldn't be elevated as an end unto themselves. Minimal sufficiency should be our goal when expending effort on anything which doesn't create business value for our stakeholders.

But we can also apply this principle to our products.

While Greg's book provides a lot of insights, there's one line which really resonates with me: "If it isn't a clear yes, then it's a clear no."

Greg provides an example of the company Vitsoe which applies this filter when hiring new staff, but the same principle could be applied when deciding what to include in product backlogs. Let's consider the example of the mice provided with the first Apple Macintosh computers. The design team at Apple could have added multiple buttons and scroll wheels the way future generations of PC mice were designed, but a single button sufficed to allow a user to effectively use the Macintosh graphical user interface.

This principle is key when defining Minimum Viable Products (MVP). A good MVP should generate empirical evidence to support or refute a hypothesis and adding features which won't directly support that learning is waste.

But minimal sufficiency could be applied beyond MVPs to general releases. By doing so we can reap some of the following benefits:

  • Reducing learning curve. One of the attributes of well designed products is that they can be used with minimal instruction.
  • Reducing ongoing maintenance costs. To quote Scotty from Star Trek III: The Search for Spock - "The more they overthink the plumbing, the easier it is to stop up the drain"
  • Reducing ongoing regression testing efforts. As system complexity grows, the points of interdependence between seemingly unrelated components makes it almost impossible to avoid regression defects.
  • Focusing development teams on core capabilities.

To quote Greg, the next time you are considering whether or not to add a feature, ask yourself the question "Is this exactly what I am looking for?"

Posted on: October 14, 2018 07:00 AM | Permalink | Comments (13)

Reduce risk by enhancing estimation

I’ve frequently said that project management is about bringing predictability to uncertainty and while a lot of my writing focuses on managing the impacts of uncertainty through effective risk management, estimation is another area where uncertainty needs to be addressed.

If you are fortunate enough to be managing projects where sufficient historical data exists to account for nearly all sources of variation then I envy you.

For the rest of us, here are some estimation principles which should be applicable regardless of the project’s domain or specific context.

  • Use more than one estimation method: Consider this a form of hedging your bets. If you derive close to the same estimated value using different techniques, the likelihood that your estimates are significantly incorrect drops. Consider combining bottom-up and top-down methods.
  • Document and share assumptions related to the estimates: It’s always a good idea to have a second pair of eyes review estimates, but without understanding the underlying assumptions which those estimates were based on, it can be very difficult to provide quality feedback. If the assumptions are not documented, it eliminates your ability to identify proactively when internal or external changes might invalidate the assumptions & their associated estimates.
  • An estimate should never be provided as a single value: Without some understanding of the variation in the stated estimate, it’s impossible to manage the uncertainty resulting from it. This variation could be stated as a range or a confidence level.
  • Discourage multitasking during estimation: Estimation takes significant mental effort and if the subject matter experts involved are distracted, the quality of your estimates will suffer.  Consider breaking up the estimation process into more short meetings as one way to overcome this.  Also, avoid estimation right after lunch time or at the end of the working day as your team might be less focused.
  • Evaluate estimates across multiple dimensions: Just as it is helpful to use more than one estimation technique, it’s also valuable to analyze estimates in different ways to try to identify flaws. For example bottom-up activity estimation will give us detailed effort data at the work package level. But aggregating these estimates by resource role or by project phase will enable us to evaluate whether the ratio between roles or phases is logical.
  • Remove the person from the evaluation: It helps to have peer-level reviews of estimates without knowing who produced them. This sounds wrong, but no subject matter expert is omniscient and our positive biases about them might cause us to unconsciously miss estimation flaws.

Improving estimation is not a silver bullet to slay all sources of project schedule or cost variation but elevating project management capability is about evolution, not revolution!

(Note: this article was originally accurately estimated and risk reduced in July 2014 on kbondale.wordpress.com)

Posted on: October 11, 2018 06:59 AM | Permalink | Comments (20)

Because "It's there" is not a good reason to pursue agility!

Categories: Agile

I'm seeing increased similarities between online hype surrounding agile and the marketing of weight loss products. Losing weight or being agile are being promoted as the main objective when both of these are just a means to an end.

We don't invest significant effort and cost just to lose weight. We want to feel better about ourselves, look slimmer for others or gain health benefits.

Similarly, agility should never be a goal until itself - we need to define what we are hoping to realize by achieving a higher level of agility.

This is an important distinction.

If our focus is purely on becoming more agile, it can cause leadership teams to define overly ambitious time frames for achieving certain objectives or demanding unrealistic levels of capability given their industry, culture or other context. This is similar to someone who doesn't attempt to connect their weight loss desires to specific achievable outcomes. Over time, this can cause the individual to engage in obsessive dieting behavior which might leave them worse off than before.

A traditional, multi-product large company undergoing an agile transformation should always aspire to reaching a higher level of capability, but it is doubtful that they will ever be as agile as a new, small startup. I enjoy playing golf and try to set achievable goals for myself each playing season but comparing myself to a PGA tour professional will demoralize me and eventually cause me to give up the game.

When managing projects, it is wise to understand what the relative priority of the constraints on a given project are. If a sponsor indicates that delivering on time is most important, then cost, scope, quality and other constraints could be subordinated to schedule.

With an agile transformation it may be advisable for the supporting leadership team to prioritize their objectives before getting started. Are they primarily focused on increasing customer value, is it about improving quality, cost containment or increasing the engagement and happiness of their team members? It can be very educational to have each senior executive rank a predefined list of such outcomes individually and then have the leadership team compare the differences in perception. This exercise might help to avoid misalignment issues at a later stage of the transformation.

If we don't know where we are going and why we want to get there, no road will take us there.

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

Risk Management is not an island!

Categories: Risk Management

Although the PMBOK Guide has individual chapters covering key project management knowledge areas, it also highlights the importance in an approach which integrates these knowledge areas in a pragmatic, tailored manner to fit the needs of a specific project taking into consideration organizational and team culture.

One of the most common examples of poor integration across the knowledge areas occurs with risk management.  Risk management needs be tied at the hip with other project management practices, but too often it is as isolated as a porcupine at a balloon convention.

What do I mean by this?

Risk is the embodiment of the uncertainty which is inherent in the DNA of projects.  Until all agreed-to scope has been delivered and accepted, risk does not disappear so why do we not connect the dots by referencing it in other key project management artifacts?

It starts with the charter – while expressing the desired outcomes and drivers for the project, there should also be coverage of the key sources of risk which could impede the realization of these outcomes.

It continues with other core planning artifacts such as stakeholder analysis documents and organization change management (OCM) plans – risks from the register should be referenced in specific stakeholder management plans and should form part of the rationale supporting your OCM strategy.

Risk drives variation in outcomes and hence the cost and time contingencies reflected in cost estimates and schedules should link back to specific risks in the register.  Risk responses for high severity risks should show up as line items in the schedule and should have been baked into your baseline budget.

Project changes should directly tie back to items in the risk register – closed and open risks.  Some project changes may eliminate certain risks – this is why one of the ways to implement the risk avoidance response is to reduce scope.  Other changes might introduce a whole new set of risks.  A well maintained risk register should be able to provide a forensic trail of project change.

Issue logs should also show evidence of traceability to risks – when known unknowns are realized as issues, linking those back to the originally identified risks provides the opportunity to assess whether there is a future likelihood of occurrence and can provide valuable input into post-project assessment of risk management practice effectiveness.

All decisions need to consider risk – analysis leading up to a decision should consider the risks associated with each option, and risk register updates should capture the uncertainties tied to the final decision.

Risk management is like quality – if you tack it on, the value derived is less than if it gets baked in as an intrinsic part of your overall project management approach.

(Note: this risk-free article was originally published on kbondale.wordpress.com in September 2014)

Posted on: October 03, 2018 07:00 AM | Permalink | Comments (16)

"The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but rather, 'hmm.... that's funny...'"

- Isaac Asimov