Throughput Planning - Why Project Managers Should Like Lean and Agile

Project managers in IT have a tough job. I've been there myself, and I have also coached a large number of project managers (PM) throughout my travels consulting for a number of organizations around the world. One of the biggest challenges a PM faces is managing the iron triangle of time, cost and scope while wrestling with never ending waves of change and uncertainty as they sheppard the team and project to completion. The typical tool most PMs have been trained on is the work break down structure (WBS) and being schooled by institutions such as PMI, that the best way to manage change and gain predictability is to track at the task and resource level. Unfortunately this approach tends to fail as project complexity increases and most experienced PMs that have the battle scars of large complex projects learn quickly that detailed planning and tracking doesn't help manage change or gain predictability. Trying to keep up with a large rapidly changing project is like playing Tetris on level 20, good luck.

Game Over - Trying to keep up with a complex project plan

At this stage of their career, the tendency is to move from detailed task and resource tracking to focus on milestones and deliverables tracking to reduce the detailed planning that doesn't justify the cost vs value of keeping it up to date. While this lighter weight approach is better as it frees up the PMs time from updating project plans and chasing people for status and allows them to spend more time on managing the client, leading the team and resolving issues, it has also has flaws. At some point in the large hairy project, the client or someone else will launch a large number of changes at the project. Change is inevitable in projects for knowledge work. During this time, the PM is struggling to answer the questions of "what is the impact of these changes?", "will we be on time?", and "what can we do to get on track again?". Tracking milestones and deliverables fails miserably at answering those questions. The PM desperate for answers and in need to "show progress" tends to fall back to detailed plan in an attempt to resume control forgetting why they avoided doing this in the first place. It's a vicious cycle and leaves the project at risk.

Lean and Agile to the Rescue

Lean and agile methods provide an incredibly easy to use technique that provides the visibility into progress without the overhead of managing the details. It's called "Throughput Planning" or "Velocity Planning" depending on what agile circle your part of (Kanban or Scrum). In Throughput Planning, all the PM has to do is make sure that the project is decomposed into a set of business valued increments (features, user stories, agile use cases, etc.) that can be worked on fairly independently of each other, are similar in size and provide business or end user functionality. To simplify this example, I'll call them features. Once the PM has the features, the last piece of information they need is the expected average monthly throughput the team can commit to. Once you have those two pieces of information, number of features and expected throughput you can then forecast the end date with some simple math. 20 features, 5 features / month means you will be done in approximately 4 months.

Benefits of Throughput Planning

With this tracking system, you have an accurate measure progress that doesn't lie easily. 5 features done in this scenario represents ~25% completion rate for the project and is a much more accurate measure of progress than tracking at the task level. It also provides an easy way to assess impact of changes to the timeline. If we add 10 new features we know this pushes the timeline back 2 months. If we want to bring the timeline back on track, the question is now what can we do to increase throughput over 4 months by 10 features (~2.5 features/month)? If we want to know if we are falling behind simply look at how many features have been completed. The final benefit of this approach is it also forces the team to deliver completed work often to prove progress, every month the team should deliver 5 features. Want to de-risk your project? Nothing reduces risk like seeing incremental returns rather than waiting for the big bang return at the end.

If your a project manager that is struggling to manage the chaos and complexity in your projects, I encourage you to take a look at Throughput Planning and look at how to make your project more lean and agile. It reduces your workload in tracking, simplifies impact assessments, and reduces risk.

The Demise of IT Business Analysts

IT departments typically staff themselves with a group of folks known as business analysts.

These folks have the responsibility of talking to folks that work in the business and translating their needs into a format that more technical folks can understand, because for some reason or other, most managers think that developers are unable to speak the same English that everyone else does.

IT is consistently cursed with getting the requirements wrong. Users, it seems, are horrible at actually reading the requirements documents they are given, worse they always seem to hate the great software that IT gives them. IT management typically has two solutions to the problem

1 - put a change management system in place that prevents those customers from actually changing their minds

2 - invest in better capability in requirements facilitation and documentation

None of these assumption address the underlying cause of churn in IT requirements, which is that today's customer economy has created an environment where the benefit  of many IT requirements are based entirely on assumptions. When these assumptions turn out to be wrong (and they often do) the business has no choice but to change direction, and fast.

Faced with this challenge IT either jumps into heroics mode or shuts down into change request mode, or worse some weird mixture of both.

No amount of requirements gathering expertise can fix this problem. 

For the IT Analyst function to be relevant in today's world requires a different set of skills. What is required is an IT Analyst who is well versed in how to reverse engineer a business plan and associated IT solution into a set of testable assumptions that can be implemented, and validated by order of highest risk. 

This analyst needs to be able to combine business knowledge with enough technical savvy to walk business customers along a journey of validated learning, guiding stakeholder through pivot or persue decisions. They need to employ techniques like Business Model Generation, Service Design Thinking, and Customer Development to provide the business with a richer ecosystem of tools to brainstorm what the future should look like.

In short Business Analysts need to become Business Technology Innovation Experts if they want to more than mere order takers.

What Scrum, Kanban, RUP, and ITIL All Have In Common (which causes them to fail)

Putting aside the considerable differences in these methods, RUP, CMMI, Scrum, etc are foremost all products, built using a traditional product development approach. 

This means they have users. Coaches, Managers, Developers, and other knowledge workers who  desparately want to achieve better outcomes delivering business technology solutions. 

These folks read the case studies that accompany these methods and dream of emulating the stories of fantastic accomplishment that come with them.

For the most part these earlyvangelists end up dissapointed.

The real issue with these methods is the product development approach used to build them.

Most of these methods were born out of the personal pain of a particular set knowledge workers. These folks then went on to build a solution to that pain.  This is a good thing, building a solution to your own problem guarantees that you will have at least one customer, and makes it likely that you are addressing a need that someone else has.

For the most part that's where the good news ends. Most delivery methods seem to be developed using traditional product development techniques, and at worst are defended like religions against any forces that might tamper with the "purity" of the product.

It seems to me that methods like RUP suffer from the former, the method is continually extended to support every kind of user and end we up with an incomprehensible mess.

Scrum seems like an example of the former, deliberately avoiding the needs of entire classes of users in an attempt to stay as true to its roots as possible. Users are left to discover the parts that actually matter, often through very expensive trial and error.

Even Kanban, my favorite improvement tool by far, suffers from owner bias, I have yet to personally witness a text book like case study of self directed evolutionary change outside of my own personal team.

Comments that people are not using these methods properly miss the point entirely.

If a product is used incorrectly it is because the product suffers from poor useability. Owners of the method have not put the right amount of effort to ensure that these methods are not only useful (they are) but that they are easily useable (they aren't).

Method owners and evangilist have their work cut out for them. The problem space is complex, the solutions complicated, and the emotional investment is often high. By their nature, improvement methods need to be both open and prescriptive, kind of like the best software language you ever came accross.

Customer Development, a technique invented by Steve Blank provides some insight on how to tread forward. As method designers we need to probe our users a little bit better than we have in the past.

1. What have users done outside our community done solve technology delivery pain, and how can we integrate the work of these earlyvangelists into our own vision of performance improvement?
2. Does our method actually address the problem, and how can we measure the applicability of our solution?
3. Most importantly, what major pain is still not being addressed by the current collection of improvement methods out there, making them vulnerable to next disruptive innovation?

Despite all the work to date, the business of trying to get technology knowledge workers to raise their game is still way more of an art than a science. All of us change agents are operating in a highly uncertain market, time to start thinking like a startup, and collectively be open to pivoting a time or two before settling into our one right approach.

Lean And Standards

 I whipped up something quickly to explain the lean approach to standards to some clients today, and thought I would share...

1) when a team starts work it has a set of standards to use that describe how to complete the work. Often these standards are based on standardized work types, but they can also be based on process, team context, or be global

2) the team has two choices, use the standard, or to suggest an improvement

3) if the teams suggests an improvement they must make a prediction of improved performance 

4) the team then completes the work, and measures performance 

5) if performance is improved than the suggested improvement becomes the new standard forthat team

6)Team standards can be spread to other teams, becoming standards that apply to processes, standard work types, and even globally. This is facilitated by various improvement events such as operational reviews, retrospectives, etc with the assistance of managers and the QMO

7) Managers can help teams by recommending optional practices and suggestions for improvements. Again a prediction should be made, work should executed for a period of time, and the results should be measured. 

This approach largely holds regardless of the "kind" of standard we are talking about. Technical, coding, process, architecture etc are at there most effective when they are measurable, and when they can changed through safe-to-fail experimentation. Managers govern the process, and make sure that standards are not just ignored, changes must go through a scientific process. 

Managers can also suggest sweeping, global rules, but again we need to measure. With Kanban our measures are based on features. Specifically throughput, lead time, failure to value ratio, and failure intake at the feature level.