Posts Tagged With: project decision making

O Pareto, Pareto! Whereforth art thou Pareto?

I recognize that unless the scope of a project includes process or product redesign most teams are unlikely to have the need to use Pareto charts, but what concerns me is that the underlying Pareto principle is applicable on a broader basis.

Had the Pareto principle been defined early in the Guide, it could have been referenced subsequently in a number of key processes including Qualitative Risk Analysis, Direct and Manage Project Work, Manage Quality and Plan Stakeholder Engagement. With all of these processes, a project team needs to identify the “vital few” elements where they should spend valuable time while keeping the “trivial many” on watch lists for occasional monitoring.

The Pareto principle can also apply to Manage Project Knowledge, which is one of the new processes added within the Integration Management chapter in the Sixth Edition. When coming up with lessons which might be applicable to current or future projects, after the team has used techniques such as brainstorming to identify a large set of candidate ideas, the Pareto principle can be used to filter those down to a handful by considering which will deliver the greatest productivity or quality improvement.

The Pareto principle also applies when we are tailoring our approach to the needs of a given project. Project management methodologies and standards are usually very comprehensive but a competent project manager needs to be able to apply good judgment in deciding exactly which practices, tools and techniques will deliver the greatest benefit.

Finally, if we acknowledge that “It depends” is the safest answer to most project management questions, then the Pareto principle is a valuable tool to help narrow our focus to where our efforts might be best spent.

 

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

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

How should I handle an agile-waterfall hybrid project?

A question which I’m frequently asked by learners attending my agile foundations courses is “I’m quite comfortable with what’s required for a waterfall project and what’s required for an agile project, but how do I plan and manage one where some of the scope is going to be delivered in a waterfall manner and some will be delivered using an agile approach?

I could plead the project management equivalent of the Fifth Amendment by answering “It depends!” which is a perfectly valid response given that the context of such hybrid projects varies widely.

In some projects, there is a very clear delineation between the type of deliverables being produced with each approach and there is limited direct integration between these deliverables. For example, technology deliverables might be completed in an agile manner whereas change management deliverables such as training collateral get produced in a traditional manner. In others, deliverables themselves are produced in a hybrid manner. For example, the web portion of a technology solution might be produced using agile methods, but the back end integration with a legacy system needs to be done in a traditional manner.

Another attribute which influences this is an understanding of who is delivering which work streams. Are they all being produced internally, or is a vendor responsible for either the agile or the traditional deliverables?

We also need to be conscious of the relative effort, complexity or scale of each work stream. A project where 95% of the deliverables are produced in a traditional manner will need to be planned and managed in a different fashion than one where the bulk of the scope will follow an agile delivery approach.

Things to consider when faced with such a hybrid project are:

  1. Orchestrating delivery cadence from each work stream to ensure that consuming work streams are not incurring prolonged delays in receiving components from providing ones. This can be a challenge when an agile work stream has dependencies on a waterfall work stream. On the other hand, if an agile work stream is delivering components to a waterfall one, there is an increased potential of component inventory buildup which is wasteful and could increase the likelihood of rework.
  2. Defining a common set of ground rules is important to avoid creating “us and them” rifts between the work stream teams. For example, if the agile work streams are able to use information radiators or other barely sufficient methods of communicating with stakeholders, figure out how the traditional work stream teams can do the same.
  3. Make the life of your approvers and control partners easier by coming up with a common method of capturing key information which they will need in order to bless your project. Requirements capture can be challenging in a hybrid situation as agile teams might prefer to use collaborative tooling such as Jira whereas traditional teams might want to use a business requirements document. Managing reviews and signoffs will be difficult, especially when the outcomes of each work stream are tightly integrated, if you don’t settle on a common approach.
  4. Finally, agile mindset and behavior need to prevail across the entire team and not just the agile work streams.

Purists will be shuddering while reading this while pragmatic realists are likely nodding their heads in recognition of how often a hybrid scenario occurs, especially in large organizations where the large variety of contexts eliminates our ability to apply a single methodology to all projects. When it comes to managing such projects a key lesson (plagiarizing Malcom X) is not to preach integration while practicing segregation!

 

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

Create a free website or blog at WordPress.com.

%d bloggers like this: