Posts Tagged With: improving project management

To avoid a dire fate, don’t forget to iterate!

Anyone who has read the PMBOK Guide or taken the PMP exam knows that project management is made up of an interconnected and iterative set of processes. Even a highly predictable project requires a team to iterate back to earlier executed processes when faced with a change request.

So why is it that we tend to forget to re-execute certain key project management processes? It’s likely because they aren’t as well understood by our team, sponsor and other key stakeholders. It’s rare that maintaining schedule or financial baselines and forecasting these project dimensions is neglected as there are usually external forces ensuring that this occurs periodically.

But let’s think about risk and stakeholder identification and analysis. Just like developing a schedule or a budget, these processes are commonly performed early in the life of our projects. But it is very common to find projects where these processes are never revisited.

The risk of ignoring them is significant.

Skipping out on full lifecycle risk management means we could continue to invest in monitoring obsolete risks while remaining blissfully unaware of new threats or opportunities. We might also be missing changes in the profile of existing risks. Some low risks on our watch-list might have increased in severity whereas others which we are actively responding to could have dropped in priority. As risk responses are implemented we want to understand what residual risk remains and update our knowledge of these risks accordingly.

The same holds true for stakeholder information and engagement activities. We might miss a new highly influential or impactful stakeholder that arrives on the scene after our initial stakeholder analysis. Or a stakeholder whom we felt had little interest in our project might become more visible than before.

We expect that overall risk and the relative influence of stakeholders should decrease over the life of a project as we start delivering scope and uncertainty decreases but if we keep looking in our rear view mirrors we are likely to miss the runaway Mack truck bearing down on us.

Avoiding this requires discipline on the part of the project manager. Consciously challenging themselves and the team to periodically revisit risk and stakeholder registers for currency and accuracy can reduce the likelihood of occurrence.

To extend Donald Rumsfeld’s famous taxonomy, we create unknown-knowns by not iterating back through all applicable project management processes.

Advertisements
Categories: Project Management | Tags: , , | 1 Comment

Minimal sufficiency applies to tooling just as much as it does to documentation!

“Working software over comprehensive documentation”

This value statement from the Manifesto for Agile Software Development is a reminder to remain vigilant that the by-products of our product or project processes don’t distract us from delighting our customers and stakeholders. For organizations which have onerous, document-based delivery standards, it serves as a guiding principle to lean out methodologies focusing on the minimal set of information required to meet delivery and control needs. This is usually accomplished through elimination, consolidation and streamlining of documents.

But what about those companies who have implemented tooling to support delivery in place of documentation? Just because we have moved from standalone documents to one or more supporting applications doesn’t mean we should not apply the same principle of minimal sufficiency.

Here are three ways I’ve witnessed this principle ignored:

  • Multiple point solutions with overlapping data elements, conflicting workflows, and differing nomenclature. This often occurs when delivery tooling is procured in a distributed manner. For example, a Business Analysis leader might select a requirements tool, a Quality Control manager has procured a test case and defect management tool and so on. Project teams get confused by how the different tools connect together and the likelihood of data accuracy, consistency and completeness defects increases. While detailed reporting can usually be managed easily, project/product-wide or portfolio-level reporting becomes extremely difficult.
  • Not disabling the fields and features which are not required. You might ask who would fill out a field or use a feature which they don’t need to, but you’d be surprised at the creativity of teams at using unused fields as a means of ferreting away some information they believe is valuable. Beyond the potential for field or feature abuse, a bigger concern is team members getting distracted or overwhelmed by the complexity of a solution.
  • Tooling which does not map to the information needs of team members. Its become a cliché, but one which continues to be ignored – don’t buy and implement a tool if you don’t understand the process it will be supporting! If the tooling does not help team members do delivery activities, then they will treat it as an afterthought and continue to use more useful, home-grown solutions.

I am not encouraging the development of delivery tooling in house or engaging in significant customizations to third-party applications as neither approach is appropriate for most organizations. It does mean you should be spending some effort up front to identify the key data elements which will be needed by different contributors to the delivery process, defining the minimal set of reporting and workflows required, involving an actual delivery team in the tools evaluation process, and working with vendors to safely disable or hide all non-essential features.

So before patting yourself on the back that you’ve migrated from delivery documentation to online information make sure that you haven’t just replaced one source of waste with another!

 

Categories: Agile, Project Management | Tags: , | 2 Comments

Problems with your Product Owner?

Scott Adams continues to hit the mark when it comes to the dysfunctions plaguing the corporate world. His latest Dilbert comic strip inspired me to write about a common challenge facing those organizations who are moving from a project-centric to a product-centric delivery approach, namely developing effective product owners.

The funny thing is that this is not a new role – go back a couple of decades and it was common to have senior managers responsible for making the majority of decisions regarding products or capabilities. As organizations shifted away from functional to matrix models, such decision-making became diffused. Also, as a company’s size grows, the authority for product decisions often moves up the corporate ladder to executives who are responsible for multiple products.

We tend to think of the product owner role in the context of agile delivery but it can also apply to traditional delivery approaches too. A key difference is that product owner ineffectiveness creates greater impact on agile projects than on traditional ones.

So what are the most prevalent peeves we have with product owners?

I’ve previously identified Capability, Commitment and Capacity as three characteristics of effective team members. Gaps in any one of these areas will translate into product quality, team productivity or morale issues.

These attributes are also important in product owners.

Managers who possess strategic vision, political influence and knowledge of a product are often unavailable to be committed to the extent required to effectively support a delivery team. Faced with this dilemma, executives usually will either still commit these managers or will have them appoint proxies.

With the former scenario, delivery teams enjoy good quality decision making but are starved for the product owner’s attention. Decisions which could be made on the spot get delayed. If the team waits for decisions to be made, productivity and eventually morale suffers whereas if they try to proceed based on their knowledge the risk of rework increases.

Proxy product owners might not have the knowledge, vision or influence required to make good quality decisions or to have those decisions stick. What sometimes occurs is that significant decisions need to be blessed by one or more senior leaders which increases the risk of delays. Proxy product owners might also not enjoy having accountability without authority and their commitment to this role wanes over time.

But there’s one more characteristic – Collaboration.

Let’s say we have a product owner who has the first three C’s in spades but they don’t collaborate well with other senior stakeholders. In most organizations there are control partners whose input needs to be incorporated into product decision making to keep the company safe. The solution lead for the product should also have a voice to ensure that technical debt or other sustainability considerations don’t impact the organization.

If the product owner is not able to effectively collaborate to distill these many voices into one, they risk alienating key partners or making decisions which will hurt the company in the long run. While the role has authority over product decision making, this should not be done in an autocratic manner.

The introduction of the product owner role is an ideal way to streamline decision making and develop future leaders but neglect the four C’s of Collaboration, Capability, Commitment and Capacity at your organization’s peril!

Categories: Agile, Facilitating Organization Change, Project Management | Tags: , , | 1 Comment

Create a free website or blog at WordPress.com.

%d bloggers like this: