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)
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:
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?"
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.
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)
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.
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)