I heard recently some people in software development were proposing that there be ‘no projects’, because ‘projects’ create batches and stifle project flow. Being a cloud-based software company, and knowing Agile, Scrum, Kanban, and Flow principles, I see how being project free works for some types of software. Unfortunately, in hardware product development, in many cases, having no project due date just does not fly.
Like it or not, organizations need to know when a product will be completed -- when they will have a minimum marketable product ready for launch (i.e., they make more money knowing and controlling). A company’s need to know the delivery date is especially true in new product development of hardware products.
Achieving flow enables confidence in completion dates. At Playbook we have found that projects flow well as well as have a known end date as long as they incorporate flow related principles and have a tool like Playbook (shameless plug), that supports them. We can have a known, confident, even a ‘specified’ end date, as long as we recognize and effectively manage most or all of the following Lean project management principles.
Recognize that project end date is not an input, it is an output, dictated mostly by the actual work required (i.e., scope and risk level) and the availability of (critical) resources to do the work. Sometimes there is also some unfilled wait time partially dictating the project end date (time waiting for parts, feedback, etc.), which is not filled with other value-added work.
To use an analogy, we can have a goal for the cost of a part (e.g., cost $20), but the cost is really dictated by the part’s design - the required material and the complexity and length of the manufacturing process – which are the inputs. Sometimes we can modify the inputs (design) to achieve the goal output and sometimes we can’t. Sometimes we have a project we can get done by the ‘due date’ with a given scope and resources. Sometimes the project doesn’t fit and is ‘over constrained’ and something has got to give. Usually that is the end date of the project, because it isn't recognized early enough.
You cannot always just add resources to meet the launch date. This chart describes the diminishing return in an ideal case where the new person needs no time to get up to speed and is fully flexible. In reality, each new person adds work to current resources to get the new person up to speed. In some cases, for example when specialty resources are needed, or when it is late in the project, adding resources may actually cost you more time than it gains you.
In Playbook terms, availability is the time per day you have available to spend on a given project task. Capacity is the total time you have to spend on everything in one day – including tasks, meetings, email, coffee breaks, etc. Accurate ‘availability’ of the critical resources is a critical component of a realistic project plan. If you plan for the critical resources to be working on their critical tasks for 6 hours a day and they only get to work on them 4 hours a day (33% less availability, on average), the project will take 50% longer than planned, even if you correctly predict all of the work (which is typically underestimated, too).
As the graph indicates, availability must be maintained on the high end (>4 hrs. /day per critical resource). Working on multiple tasks or projects drives your availability to the low end. How much confidence do you have in your completion date then? This is where other key elements really help – time blocking, demand management, and minimal multi-tasking.
Project plans and schedules are a ‘model’ of the project, the same as a CAD model is a model of your product, except with a lot more uncertainty in the elements. You can build a more accurate plan (project model) by determining what work is involved in the work driven tasks and estimating duration from that.
When estimating duration only, you combine both the variability in the work and the variability in your availability. The graph above shows the effect of overestimating availability, which is almost always done, and this is one of the reasons why traditional project schedules are so bad at predicting completion dates. It is better to KNOW your availability and estimate just the work.
Drastically reduce actual work (both predicted and unpredicted work), and unfilled wait time by using risk management and ‘early learning’ principles found in Information Theory, Lean Startup, and throughout Don Reinertsen’s teachings. This is the key to breaking the current ‘iron triangle’ myth.
For example you can minimize unpredicted work, not by avoiding risk, but rather by identifying it, asking why 5 times to determine what you really need to know, identifying good fast-feedback mitigations, and including the mitigation work in the overall plan (i.e., mitigating the risk leanly and effectively) especially in high-risk areas first.
Of course, recognize what the product requirements REALLY are and what the customers REALLY want to buy. These are key risks. Mitigating these risks in a Lean Startup way is one of the keys to reducing wasted work and time. Don’t do anything that doesn’t have a good ROI to it.
Scope is directly correlated with work. The iron triangle isn’t really ‘scope, schedule, resources’. It is ‘work, duration, availability’. And it isn’t exactly a triangle. (See the graph above.) But it can be seen as such.
Make sure tasks have a clear Definition of Done, use test-driven development, and don’t buffer each task but instead using a ‘right-sized’ project buffer. And make sure downstream people (e.g. purchasing, manufacturing) are never overly critical of what they see early. This causes the engineers try to get it too right before they let go.
Recognize the work you need to do usually DOES include Risk Mitigation, though. In the long run, you will do less work mitigating the risks than reacting to them later. But not all risks are worth mitigating. How do you know? There is a formula.
And, we can’t usually think of all the risks there are. We must let go of things before we are ‘done’ to get the feedback from downstream. There is a formula for this too - when is the right time to stop working on something. These formulas will be a topic for another article, though.
Good planning is risk mitigation. You will think about, talk through, and eliminate ‘flow’ blockages before they occur. The ROI on planning is huge, but that will be the subject of another article, too.
In addition, a good plan (project model) has enough detail for it to be predictive of how much work is really going to be involved, and therefore, when you will be done.
I know some people will cringe at the thought of having a ‘detailed’ plan. The only way this is possible is by having a tool like Playbook, where entire task chains can be easily copied from a library or another project, and then ‘pulled’ and ‘consumed’ rather than ‘updated’ once a week. Once a task is complete, the resource marks it complete in 1 second, that day. Nobody has to ask them – and the plan is constantly up-to-date.
Records of past plans can also help, as an input into how much work will really be involved in the various tasks. And how much ‘unpredicted work’ there typically is during a project. Again, this is only possible with a tool like Playbook, where the records practically keep themselves and are always easy to look back on. Yes – of course every project is different, so we don’t expect it to be the same every time, but estimates based on historical data are much better than estimates pulled from distant memories, or worse, thin air.
A good plan also determines what and who is really ‘critical chain’ and what the best priorities are for the shortest probable schedule for a given project. Combine this with Cost of Delay, and you can get clear priorities across projects. Then you can focus the resources and work on the truly highest priorities. Again, enough detail and some data to back the ‘correctness’ of the plan and the resulting priorities is key here, which is only possible with a tool like Playbook.
Be flexible on scope from the beginning of the project, and stage the low-value ‘features’ to the end in case some need to be cut to meet the schedule. This takes good up-front planning and architecture, especially in hardware development projects. In general, a good modular architecture for the product allows you to distribute the work better, across more resources and make faster, safer changes.
Two other methods are key to have confidence in your project completion date – well run daily meetings and visible work. Daily meetings are critical to maintain flow and enable the team to see the queues, manage the queues, identify where team members are multi-tasking and eliminate it. The old adage is 'you can't manage what you can't measure'. Well, you can't manage what you can't see, either.
Minimize the (unnecessary) work, create flow and maximize the critical resource’s availability. Get your projects done as fast as possible and ‘on time’. If it looks like it isn’t going to happen, and you see it early enough, you have the ability to do something about it. If you don’t see it until it’s too late, the project will be too late.
----
Do you know the number one cause of project delays? It's not what you think. Watch this 9 minute video to find out.
Lean project management
Lean project management methodology
Lean project management Kanban
Lean project management principles
Lean project management resource management
Lean project management Pull vs. push
Lean project management task management
Lean project management and shared project buffers
Lean project management and decentralized planning
Daily stand-up meetings
