Targets and Trends
/
A target date is a point in time, in the future, that something is needed. It is essential for measuring the performance of a project. Is the project getting closer to hitting the target date or is the project trend showing that a team is predicted to miss the target date? And by how much time? It only works if the target date is real, and one that the project stakeholders agree to, in advance.
But where do target dates come from? Where should they come from? What is their purpose and what are they used for? The following is a discussion that tries to answers these questions.
Lets list the purpose of a target from two perspectives; the best in class teams/organizations and the normal teams/organizations.
Best Teams
To align marketing, engineering, and manufacturing operations (before a project starts).
To track the trend of a schedule, in order to…
Get early warning of potential problems, so a team can take advanced action while there is still time.
Normal Teams
Use as a gaming device between marketing and engineering functions.
Use to punish people for failing to meet the unreconciled aggressive goals.
Use as a drop-dead-date from which to work backwards to compress/fit a schedule.
I will come back to these six ideas, but first lets explore the concept of a target in a more abstract example.
Let’s assume I have decided to build a quest house I designed. I retain a contractor. I estimate that it will take him 4 months to build and I set the budget at $50k, knowing it should cost more and take longer, but also that this is my opening negotiation position. The contractor looks at the drawings and bids 8 months and $100k.
He has done the reverse of what I did. He bids high knowing he will have to come down and I estimate low knowing I will have to come up. He thinks this gets him more money and time, while I think it saved me money and time.
We “negotiate” - the time and budget move closer to one another in the process. The problem is that it has nothing to do with the real cost or time it will take, but rather each side trying to get more from the other. In the end it may take 12 months and $150k to do the job correctly (this was the real time and cost based on the design requirements), and both sides are surprised later when the project goes over budget and past the target end date. The contractor was counting on change orders to make up the differences and I was counting on holding the contractor to his fixed price bid. It is why most construction projects end up in some form of litigation; both sides fail to reconcile the time and money needed to meet the project objectives.
Now lets add one more variable - the reason why I need it in 4 months. It is because by Mother-in-Law is visiting and plans to stay with us for a few months. She arrives in four months, this is a fixed date based on her plane tickets. So I must have it ready. This is the reason behind my target date, which sets the overall duration of the project at four months. My backup plan is to have her live in the house with my wife and I if the guest house is not finished, but since we don’t have much space, this is not a satisfactory long term solution (for me at least).
In the first example, the target was used as a negotiating point, but it had no basis or justification. There was no driver. It was just a date I was using to get someone to work faster. In the second case, the four month window was based on a real reason for it needing to be completed at a specific point in time. My cost of delay was measured in the anticipation of living under the same roof with my Mother-in-Law for an extended period of time!
My Mother-in-Law example is not far from real product development projects we work on with clients. Most of the time these dates are internally driven by marketing, product groups, or customer-facing business units. They are loosely based on when they expect competitors to have a similar product or when they expect customers to need a given technology capability. Sometimes they even ask customers when they want something.
But somehow this raw and pure customer data gets “refined” and “filtered” by customer facing groups, because they know that if they need something in 6 months, it is better to ask for it in 4 months, based on the past performance history of the engineering teams that failed to deliver on time.
They think that this makes engineering teams work harder when the bar is raised higher, so they will get it in 5 months, 1 month ahead of schedule. But like my Mother-in-Law game with the contractor, these dates have no basis in logic, but rather are just points of negotiation. The real end date for my guest house should be based on the time it takes to build the design that was specified in the drawings and the risks factored in to consider of the unexpected (weather, design changes, material delays, etc.). In the end, no one knows where the date came from or what it is based on when it is not based on facts, but one thing is certain; what ever date is given, you can bet that someone will want if faster. This is what stimulates the date game cycle.
It is very hard to make teams go faster when you can’t explain to them why something is needed at a given point in time versus some other later date.
So where should a target date come from in a technology product development project? It should come from the customer. There is a point in time when a customer needs a certain technology capability. This is the target date or a target window that defines a quarter in a year when something is really needed. This is the only date that matters and one that is not a point of negotiation between internal stakeholders. If the customer-driven date can’t be achieved, then kill the project before it starts, but don’t start it hoping that a miracle will occur at some point in the future to make the impossible possible.
There is a cost-of-delay for being late. This cost is measured in lost profit and is based on a loss in market share or sales when a technology is delivered late. Having a justifiable target date from the customer is quantified in the cost-of-delay model.
If “lateness” can’t be quantified, it suggests that the target chosen may not be the real need date. The process of modeling lateness should be done with marketing and engineering stakeholders, so that both sides grasp the implications of being late and are forced to work through the logic of a target market window. For most projects we work on, the average cost-of-delay (per day) in lost profit for being late is between 1 and 2 million dollars a day. But this all starts with a rational foundation for the target date or target market window, after which time you are late.
We also see the use of multiple dates to define the project target. This always leads to gaming, like the game I played with my contractor. It wasn’t until I introduced the information that my Mother-in-Law was arriving on a fixed date that the rational behind my four month target window was clear. Given this clear motivation for having the guest house finished, I might have been forced back into the project specifications to redefine the scope of the project to fit the target window or maybe had incremental phases of completion to make part of the house livable in four months with other less important spaces coming on line later in time. I would have done this with the contractor as a partner, instead of the advisory I was trying to get as much out of as I could.
Inside and outside dates are bad, like a BU’s need date vs the Team's Commit Date. Sometimes we see a date that they tell the customer versus the inside date that the team works to. Lots of dates like this just cause people to game the system and confuse people - which date is real such that if we miss it we consider the project a failure, our internal engineering date or the BU’s date or a third date which was actually when a customer wanted it? We have seen this hundreds of times, multiple dates never work. Theoretically they sound great, but in practice they fail.
So there may be a need date (1) from marketing/customer facing business unit. Then there is the date a team commits (2) to delivering the project. Then there is the actual date (3) a product is going to be delivered, that should be based on the critical path schedule which forecasts the project end date. But which is the real date?
Marketing raises the bar as high as they think they can get away with and Engineering lowers it in order to reduce the risk of failure. In all this organizational gaming between adversaries they tend to lose the real date that something is needed.
There is only one real date and this is customer-driven. This is when the customer tells you that a technology capability is needed. They will get it from you or someone else if you are late. This is how you calculate the cost of being late. Need Dates, Commit Dates, Actual Dates are meaningless at the end of the date, but make for good inside company politics as people try to hide behind them when projects fail to deliver on time.
Marketing - “They missed our target date again, this is why we lost the customer’s business…”
Engineering - “The date was too aggressive, we told them, and the technology too complex for the time we have to develop it, so it is not our fault that we missed the unrealistic date… besides, the requirements kept changing”
Best and Normal behaviors
Best
1. To align marketing, engineering, and manufacturing operations.
The simple solution is a single Target Date (or target window) that is mutually negotiated between the BU and the Engineering Team, and then a projected milestone date based on the calculated critical path. Marketing’s job is to communicate the reasons why the customer needs it at a given point in time or why they feel a competitor will have a competing technology at a given point in time, or why they believe market segment leaders will need x functionality by y date. Engineering’s job is to communicate the technical implications of x and y; what building block technology is needed to make it possible, what already exists that can be reused, the problems of integration, and the risks of trying to do it.
But in the end, there really isn’t a negotiation. The date or window is/should be driven by the customer need. If this date can’t be met with x functionality, then don’t do the project. Kill it before it starts, but don’t start it with both sides unreconciled.
There should be only one gap analyzed; the gap between the customer need date and the projected engineering end date based on their critical path calculation. The more advanced organizations measure the end point from a customers perspective; which is when volume manufacturing is running at stated yield and cost targets.
The operative word “mutually negotiated or reconciled.” which forces the BU and Engineering to reconcile and align around the same target. Take away the negotiated part and allow two dates (marketing’s need date and engineerings commit date) and you never get the two sides to reconcile. But sometimes they don’t want to reconcile, because the lack of pre-project start alignment can be used later as an excuse when the project fails to deliver on time.
There is only one target date, which should also be the commitment date and also the date the customer must have it. The second date is when a team feels they can deliver it, based on the critical path to that milestone.
2. To track the trend of a schedule, in order to…
The point of a target date is to measure the performance of a project. Assuming it is customer-driven (point 1 above), the question is if the team is moving away from the target date or towards it, once the project gets under way. The direction of the schedule trend indicates the health of a project. But the health is relative to the target. If the target is gamed, then the complete system falls apart.
3. Get early warning of potential problems so a team can take advanced action, while there is still time.
Knowing a problem in advance of the problem hitting is sometimes the difference between success and failure on a project. Most teams can solve a problem when they have enough time. More time can be come from looking ahead and predicting the problem in advance of when it happens. That advanced warning time is the time teams need to explore solutions.
Again, the system breaks down when the target date you using to measure the health of the project is not based on customer-driven information. Since being late is all relative to that “stake someone put in the ground.” When that date is real and backed up by a cost-of-delay model, it is much easier to create the energy to find solutions to hard problems, because the fear of failure is real and its costs of lateness are rationalized.
Normal
1. Used as a gaming device between marketing and engineering functions.
Marketing raises the bar to get it faster, while Engineering lowers it to reduce risk and protect themselves with buffer to account for the inevitable future scope changes and technical problems they expect. At the end of the day, all the gaming of dates results in a schedule where no one really knows which date is real and which date has been manufactured to protect one party of another.
2. Used to punish people for failing to meet the aggressive goals.
The aggressive date demanded by marketing is never agreed to by engineering and manufacturing. Yet the project starts off using those dates as the metric to measure performance. No one on the engineering team buys into these dates and never takes them seriously, since they know the technical risks of trying to meet them in time with an acceptable solution. And the engineering team has their own internal date they are committed to anyway, so they ignore Marketing’s date. This is the real target date they tracked to and measure their performance against.
When the project starts to slip, the aggressive and unreconciled dates become the stick with which to beat the teams. The more they get beaten, the less enthusiasm they have for meeting those dates. This usually results in a “change of leadership” to install people that can “get the job done.” When all else fails, have HR or a Consultant to run a team building class or blame the complexities of the technology for the failure!
3. Used as a drop-dead-date from which to work backwards to compress/fit a schedule.
The aggressive end date set the window. The engineering team then manufactures a schedule to fit nicely inside the time window. No one on the team believes it is possible, yet no one says anything because it could be career limited to voice an objection. Of course what is lost in the process is the missed opportunity to reconcile the differences, understand alternate view points, and to explore solutions to close the gap (since there is none at the start of the project, which is force-fit to the time window).
Conclusion
Target dates/windows come directly from the customer (or an estimate of market need or an assessment of competitive forces). There is only one date when something is needed.
There should not be multiple inside and outside dates, this only leads to gaming the system.
Being late is quantified as a cost-of-delay in lost profit every date you pass beyond the target date.
The process of reconciling the date between marketing, engineering, and manufacturing is critical to each side understanding the rational for the date. Don’t miss this alignment opportunity by allowing multiple dates.
Use the information to track trends, assuming all stakeholders buy into the target. Use it to assess the heath of a project and to spot problems before they happen, in order to give a team more time to find the solution.