I heard recently some people in software development proposing that there be "no projects," because projects create batches and stifle flow. Being a cloud-based software company, and knowing Agile, Scrum, Kanban, and Flow principles, I see how that works for some types of software. It works pretty well, when you can do it. But, unfortunately, in a great many cases, the approach to new product development with no project due date just does not fly.
Like it or not, good at it or not, some organizations need to know, E.g., they make more money knowing and controlling, when the product will be done -- when they will have a minimum marketable product, ready to launch.
A company’s need to know the delivery date is especially true in new product development of hardware products. Here are some reasons why: There is a sales and marketing team to hand off the product to when the product is complete. If the sales and marketing team know when the product will be ready, they can be ready to run with it.
The manufacturing department will be full in the 4th quarter or whatever the busy time is for that department. If the product gets done then, it will sit in the queue waiting to be built while the production line fills existing orders.
It is sometimes the case that the company is replacing (cannibalizing) an existing product, and they need it to sell out, but not sell out too early. Scrapping obsolete parts and whole products is costly, as is being ‘market dead’ by not having product to fill orders with. (Lean manufacturing helps eliminate this risk.)
There are other cycles to fit into. For example ‘be on-time for the Christmas rush’ or, as with Apple iPhone accessories, ‘be there when the iPhone gets there’, or be dead.
There are trade shows or sales meetings. If you miss these, you lose mindshare of customers or the sales force and realize a drastic jump in 'cost of delay' (more on cost of delay later).
Sometimes you need to tell your shareholders what you are doing with their investment and when you will be launching the next big thing.
Good flow is what enables confidence in completion date. At PLAYBOOK we have found that projects can flow as well as have a ‘known’ end date as long as they incorporate good Agile and Flow related aspects, 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.
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 Relay 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 good project 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.
We all know engineers will work until their time runs out, at least until they've converted to a Lean Startup or Relay mentality. We engineers are not the only ones with this natural tendency, though, partly because there are forces in companies today which promote that behavior. And this is not good for confidence in completion dates. To combat this, 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 (e.g., PLAYBOOK software). 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.
Interested in learning more about Lean project management? Watch this on-demand webinar series. It's free.
You can also watch a demonstration of PLAYBOOK lean project management principles and software.
