These are techniques for beating the initial, actual schedule and/or budget without giving up anything the customer cares about.
I have used all of these, and can vouch for their effectiveness. Of course, the situation dictates which would be practical, but I hope that you find some of them useful and effective.
Lets start with some facts. Hard proven, again and again.
This means that you have actually achieved more than you had planned at some time during the job. If you do not accomplish this at least once, you will not meet the schedule or budget. Unless it all comes together on the last day. Like that's gonna happen.
Corollary:
A corollary is that if you execute the initial plan perfectly, you will fail, because things will go wrong. If no improvements are implemented/encountered that offset the setbacks you certainly encounter, you will not meet the original schedule/budget.
Therefore, your aim should be to identify the actual, verifiable milestones, and try to figure out how to get the each done a bit sooner/cheaper. That way, when things go wrong, you will have some slack to cover it. During the proposal process, this is what was done to make the job more and more attractive, until it is finally won/turned on. Why stop looking for ways to improve the chances of finishing under budget when the contract is awarded? If you wait until something goes wrong to try to find an offset, it will probably be too late.
In fact, many programs are accepted with a challenge to knock some time/cost out of them. The business plan is counting on someone doing this. In this case, you are behind the schedule and budget on the day you start (sound familiar?).
A method of measuring this schedule metric quantitatively is referred to as slack. So the goal here is to create slack. For budget, this is creating reserve. Of course, giving it a name doesn't tell you how to create it - ideas for this are below.
Be aware that it is typical for initial slack to be burned by functional managers at the start of a task, usually as they try to complete other projects that are not quite finished. They can also remove risk from their effort by starting late. See the Dark Side of Project Management for an article about this.
Also be aware that formal Earned Value Methods interfere with the creation of slack or budget reserve. The formalization of planning drives the Cost Account Managers (CAMs) to use their entire cost/schedule budget to reduce their personal risk, rather than revealing improvements they may develop or discover. More on this later.
To formalize this results of schedule/budget improvement efforts (and it is an effort you must actively perform), I recommend presenting these two summaries at a monthly review:
The first slide covers the negative results, of setbacks encountered, and their approximate impact. This is typically a part of any progress review. Examples: This part hasn't been received, the latest build was not testable, this guy quit, etc.
The second slide covers the positive results – things that you have done or discovered that have improved your chances of meeting the schedule or budget. Make sure you some things to put on this slide.
The negative results typically happen on their own, due to external events. The better than expected things you and your staff have to make happen, but you may get lucky breaks. Using this setback/breakthrough presentation technique really sped up our internal reviews. It was pretty much all anyone wanted to see, may as well get it out there in black and white.
Do not wait for an individual, department, or subcontractor to have a schedule problem, then try to force them to rectify it without affecting any of the other efforts. While this may be morally appropriate, it almost never works. By the time the problem shows itself, it is usually too late to be corrected within the bounds of the design responsibility, and your time may already be up.
Example: Development of a new interface took two weeks longer than planned. This would be reported on the first slide above. Not good, apologies, upsetness. However, some time ago, your team figured out how to reduce the time needed for integration of that interface. Should save about two weeks (second slide above). So in spite of the setback, still on schedule!
Rx: Realize that setbacks are a fact of life. Find schedule/budget improvements from the start of the job that will compensate for setbacks. They are there, just like the setbacks.
Manloading determines how many contributors should be briefed into the job. This sets the width of the design responsibilities. The following must kept in mind.
Most people cannot work forty hours a week on a task. They have legacy responsibilities they must attend to. Perhaps new employees can be this dedicated, or contractors, but this is offset by their efficiency factor as they come up to speed on corporate procedures and culture. Don't be surprised when almost no one can work full time on your job.
Rx: Manload individuals at 140 hours/month to account for diversion due to legacy work, or plan for overtime.
Classically, 152 hours per month is what is used for full time. This assumes 10 days vacation, 10 days sick leave, and 8 hours/month overhead (training, corporate meetings, seminars, capital projects). All staff members achieving 160 hours (4-40hr weeks) every month on your job would be very rare. Assuming perfection is folly. How tight can your organization run?
Project planning tools have methods for loading holidays into manpower planning, but I have found these to be more trouble than they are worth. This is useful for scheduling events, but for manloading, not so much. It is far more useful adapt the plan for Resource Constraints.
Manloading must be ramped up at the beginning and down at the end. Assuming the project will be 100% staffed on day one is unrealistic, and actually having all that staff on day one may wreck the job. See the Panama Canal for a splendid example of a job ruined by starting with a full staff on day one.
This means that a 12 man-month job, to be executed in 4 months, will require many more than 3 people heavily contributing at the center point.
Rx: The number of designers that need to be briefed into the job will be 1.5 to 2 times the average manload, or more. A 12 man-month job, to be executed in 4 months, will require 5-6 people to be briefed in.
Setting the manpower is important, in that the width of the design team is a sunk cost. Be aware that minimizing the cost of briefing people in inserts risk into the schedule - if you get in trouble, you cannot bring people up to speed in time to help you. Train some spare resources so they are handy as a risk control mechanism, if schedule is more important than non-recurring cost.
When manloading, 1+1 = 1.5, maybe 1.8. There are some exceptions, but in general you can count on this.
This is because communication takes time, complicates documents, and adds the possibility of errors and conflicts. Doubling the bodies will not halve the schedule.
Exceptions:
Application of legitimate experts
A legitimate expert needs little preparation, understands the requirements of the design field better than the other staffers and in general will solve the problem with little assistance. Adding the right person can be a real boost.
Simply picking someone and calling them the expert does not accomplish this.
Note: you may be able to use a capital project to create an expert using training or other means before the start of the project.
It is a bit of a crap shoot. If you are slightly off the experts knowledge base, you will not get an improvement. This may, in fact, drive your design as you gravitate towards what the expert is best at, not what your firm is best at.
HI/LO team of engineers on a complex task
Not all tasks in a complex design require a very experienced person (HI). Having a low cost person (LO) do whatever they can do saves dollars, and is good for the growth of both individuals and the organization.
HI cannot move on until LO can hold his own.
LO has a clear goal – to work HI off the job.
Their combined costs offset, and the result may be greater than 2 if Lo turns out to be talented.
Rx: Factor in a drop in efficiency when increasing staffing to improve schedule performance, unless it is one of the two cases above. If you have to, show it as a communication effort (specs, test, etc).
What will be different to cause the schedule or budget to be improved?
"We'll do it right this time!!!" Yeah, sure. If the same people do things the same way, you will likely get the same results.
Even if the participants have more direct recent experience than before, that likely has been factored into the allocated budget and schedule, as shown below. During any proposal, improvements over last time are assumed. During execution, you must implement these improvements. Some are known, some you will have to come up with.
Example: Write a support document
Typical process improvement assumption is shown below.
Conclusion: We must do something different than last time to get from 114.2 to 77 hrs. Just correctly executing the same process will insure you overrun your budget. Some changes have probably already been put in place, but some of the changes will undoubtedly be new to make such a reduction.
It is unrealistic to try to simplify or improve all tasks – but you have to do it on some. Capitalization, training, all sorts of efforts are directed at reducing the effort required to accomplish tasks.
Rx: Identify the tasks you are going to improve, and and use the techniques below to improve the schedule/budget over last time.
Below are some practical techniques. It would be rare to use all of them, but at least a few may fit your your needs/abilities.
There are well established methods of improving either the Schedule or Budget at the expense of the other. Part of engineering is studying a problem and finding a better way to do it by parking minds on it. And minds cost money.
Schedule important? Go to the Schedule Priority Page.
Budget important? Go to the Budget Priority Page.
Checking is the most efficient effort, man-hour wise, in the engineering world. If an engineer spends 8 hours checking a design, and finds a bad body and a missing track or a bolixed API - he has easily saved the company 16-40 hours of rework, and maybe more if a problem does not show up until qualification testing. For support documents, a sentence that is incorrect or unclear may result in hundreds of service sessions by voice or email. Fixing these problems before they hit the line or the field will save quite a bit of effort.
A review of a software design can turn up holes and traps. I have been in reviews that cut the actual work of the coding effort in half. I have also been in reviews where 50% of the functionality was just not in the design as presented (oops). These reviews resulted in huge actual cost savings, compared to if we had just gone ahead with the existing design.
It is also the least desirable engineering activity. No one wants to check. No one likes these reviews. And when you are checking, you really don't know what you are looking for, which means to a business person, it looks like a total waste. And there are diminishing returns.
To motivate the engineers, I tell them that, for example, we typically find 4-5 errors on a completed design element in debug, test and field service. So those errors are in there, before we begin implementation, right now. Finding even one before we build and integrate it will save big bucks. Keep checking till you find a few. They are there.
One technique I used to make sure that people were checking the entire documents I produced, was to place a sentence or circuit that was total nonsense in the package. If the check was completed without finding anything worth fixing, I pretty much knew they didn't really check it very thoroughly. Once it got out I would do this, it actually made it work better, as people went looking for the nonsense components.
Apparently the rock band Van Halen used this technique also. Their contracts required a bowl of M&Ms, with NO BROWN M&Ms, in their dressing room while on tour: (Look at the Van Halen Contract). Arena rock concerts are complex affairs. If there were brown M&Ms in the bowl, then what else was missed? Perhaps the ground isolation requirement?
It is tempting to show progress by banging out easy tasks, and making everyone happy, but this is not a good idea. Doing the easy stuff first will make people happy at the beginning, since you can show so much progress, but it will probably make the hard stuff harder. If you do the hard stuff first, your solutions to the hard problems might make the easy stuff a little harder, but that is no big deal - since they were easy to begin with.
I have been called in on a few jobs where the hardest problem was left to the end, and they were no fun.
Also, if you do the hard stuff first, you can pile bodies on at the end to do the easy tasks, to bring in some schedule if you have the bucks. Lots of easy tasks are easy to delegate and manage. A few hard problems are much more difficult to apply resources to. They usually require more overhead to bring in the right resources and the result is more unpredictable.
You can save a lot of effort by reusing a component exactly as is, up to 100% of the design cost.
Microsoft freely reported one of their metrics that was a little scary. They said that in their software development cycle, 90% of costs came after the first compile. To me this says a lot about their design methodology, but there is something relevant here.
When you reuse the basic design, but touch everything with minor changes, then you do not save much budget or time, if any. This agrees with the Microsoft metric above. Anything you change has to be verified, which means it must be built, and a procedure written, a new release of control documents, etc. Also, the old design probably has some baggage - obsolete parts, techniques you no longer want to use, performance problems, etc. And you are depending on the original design having the flexibility to work with the mod, which is not guaranteed. Hello! It won't quite do that!
To reuse code or electronics effectively, you must not modify them. At all.
If they were modified, then about a 10% benefit is all I ever could realize, with one exception:
If the reuse is by the same designer, then you can get learning curve improvements that are considerable. In this case you are really reusing the designer, not the design.
But unless you use the exact same element, by control and revision number, you will not reap much savings. When you do reuse the same design, you reuse the drawings, test procedures, debug techniques, test results, labels - everything.
This breakout is an important part of any planning exercise, and not just for control purposes. This is called "Crashing" in the PMBOK.
The more partitioned and smaller the design responsibilities are, the more tasks that can be worked in parallel. This greatly improves the schedule as shown in the Serial/Parallel Article. It also results in the following penalties:
The requirement and design responsibility partitioning is more expensive. Interface documents, no matter how rough, take time and are the source of misunderstandings.
More overhead is incurred as more individuals have to be trained/briefed into the project and managed, and
More detailed integration planning and execution has to be implemented
So you just can’t just add engineers, and improve schedule. More work has to be done to define the partitioning, interaction of the designs, and the integration and test. This increase in load is usually overlooked, and the Project Engineer may end up overwhelmed by the requirements and integration effort of a job that started with three engineers, but has been broken out to allow ten to work simultaneously.
One inefficiency to be aware of is to incur the overhead of a highly parallel effort, but under-staff the effort. Then you pay the cost to prepare for parallelism, but do not reap the benefits in terms of schedule performance. Once you are in, you have to go all in.
I have seen some planning software that treats individual requirements as if they were design responsibilities. While there are designs that implement only one requirement at a time, like software features in existing products, this does not apply to new designs. Any design is an implementation that integrates a collection of requirements under the specified conditions to produce an emergent capability to meet those requirements. In the end, an individual must be assigned or assume design responsibility for a function or emergent capability that can be understood, executed, and tracked. It is rare that one requirement completely describes a function.
The wider the design responsibilities are for each individual, the less need for detailed requirements. Of course, you lose visibility and speed. And the loss of visibility can cause its own problems. Some managers like the requirement breakdown as a discipline method to add visibility, whether the design will be implemented by several designers, or just one.
Even though you may be able to break up the design into many sub-designs to be pursued in parallel, they all have to come together in the end. As this happens, the staff will shrink as a team finds the integration problems and starts rework. Don't forget to plan how the elements come together. It is natural to assume that all other components are mature and tested when your component is ready to be integrated. This will only be true for one of the sub-designs. What about the others? Let people know who is first, second, third. And be prepared for several integration stages. See this article for more information: Planning Integration Based on Component Maturities.
Examine your schedule for the critical decision days - when to start an integration, when to send out for quotes, when you have to turn on a vendor. The rest of the plan will revolve around those. The earlier you make these major decisions, the sooner the program will finish. But too early, and you will incur greater risk, and will have to backtrack. Life's a bitch. So spend your time identifying and worrying about the most important decision points, and be sure they are well supported.
Optimizing a schedule involves choosing the best moment to set the pencil down and go. Building a sample for test, for example. Too early in the design, and the results are not conclusive. Problems may remain to be found. Too late, and problems discovered cannot be properly handled. All the planning tools are set up to help you find the best place for these points. Oh, and don't expect the dates chosen for these decision points to please everyone..
This is a technique loved or hated. These are also called stand up meetings, because they are intended to be brief enough so that people do not even need to sit down. Scrum methods include this, although I believe daily status meetings were invented by Genghis Khan.
The good reasons for having a Daily Meeting:
Engineers are sharing assets, or contributing to a single entity. The meeting dispositions assets based on daily questions like:
Is it up and working?
Who needs it?
What needs to be functional to support the next user?
What is the latest version?
Who has it checked out?
Do I need that change?
When will I get it?
It is useful if interactive decisions are happening very quickly, like getting a prototype or a build together that may turn up a few lose ends. You cannot predict who will be needed.
A deadline for many small things is approaching, like a pilot production run or a customer quality review, and tasking will be moved around depending on who is where on what.
Good meetings use the marsh board, or these days, a wiki or website, to post the current status of builds, assets, test successes, etc. In general, the good daily meetings occur during brief, intense integration efforts (which may be proposals), and are suspended when no longer necessary.
The bad reasons for having daily meetings:
Team members are not communicating.
You have overlapping responsibilities, or gaps between responsibilities due to incomplete definition.
To help the project manager work directly on plan updates. If it is a plan, should you really have to update it daily? If you are, you are following, not leading.
Non participants want to drive home their positions.
To show "management resolve"
Bad meetings leave people wondering why they showed up, and can shatter discipline.
Bad daily meetings tend to become an accepted practice, with little actually accomplished. At some point during every program, daily meetings are necessary, but do everything you can to postpone them, and end them as quickly as you can. People are more efficient if working alone, as long as they are headed in the right direction.
This needs to be something very straight forward - when a hardware engineers prototype is delivered to him, he is probably in a lot of critical paths. Tell him. Tell him to take the week off before, as comp time, and work 80 hours when it shows up. Make it clear that this is his moment. Most engineers will really respond to this, especially if preceded by a break, and you let them know the following organizations that are depending on them. There is no stronger leadership step than requesting someone be ready for something important, and then showing up with it exactly on time, and saying "Ok - time to knock us out"!
We once ended up with a critical piece of software as a lynch pin of performance testing. I visited the developer and explained to him, that due to a complex combination of events, his stuff had to hit the unit rock solid. Once it did that, the test crew would take over, and he could relax. He parked his brain on it, and came up with code that resulted in the testing going so flawlessly that we finished on the first pass - boom, three weeks earlier than projected, and now we were ahead of schedule.
Tell people when their moments are. They will step up.
Just make sure they are truly moments, not weeks or months. That doesn't work. And the following users have to be ready, or else the effort is wasted.
Look here for an article on this. Even if the priorities are not "official", you should know how the project will be graded.
Define pass/fail criteria before starting tests. Often, getting the test people involved is a good mapping into an alternate space, where many errors can be flushed out before a single part is bought. Test preparation should be in parallel. On a healthy project, the test people are arguing with the designers over requirements early on.
If you decide to characterize a parameter rather than verify it to a requirement, be sure this is defined clearly.
I see this mistake made all the time. Don’t run a test if you don’t plan to put in corrective action for non conformances. The (engineering) reason you are running the test is because it might fail. Put this time in for rework, and regression testing. This regression may not even be on the unit under test, it could be that the procedure was improper or impossible to execute as written, or tests for something that isn't needed.
It will never be easier to make a change than now. As a friend of mine once said, "as long as we are fixing it, we may as well make it right".
Engineers can share resources, in fact it makes the process better.
Maybe it is just my generation that recognizes this. I come from a time when we shared everything - TVs, phones, bathrooms, musical instruments, etc. Now everyone has their own. My wife even has her own sink.
When you are checking out your design, you should spend half the time using the integration environment, and half the time fixing what you find using your development environment. People who spend all their time on the live equipment fixing things are probably hacking. The problem with hacking is that if you do not know what was wrong, and it goes away when you make a change, you do not know why it worked. As such, you do not know when or if it will be back. So someone who cannot work on his problems without the actual equipment may not be a very good designer. I have seen hackers wreck a program, turning simple integrations into dreary, never ending affairs, as solution to one problem causes another to appear.
This can be handled up front with a prototype allocation plan. Build one.
I realize that recently (this century) hacking has a more positive connotation. This may be appropriate for small modifications to largely stable products, but hacking a new design into existence will result in endless problems. I know, I have cleaned them up. Do the analysis, do the unit test, make sure it is right before you integrate.
Below are two actual examples of summary corrective action presented at design reviews on programs that were in a lot of trouble, scrubbed to protect the innocent. These were both presented as the way to get a program back on track, at the same review. Note the difference between the leadership style on the two programs.
Program #1 - How to Get Back On Schedule
Dedicate a core of talented engineers solely to the critical program tasks
Eliminate other distracting activities or assignments these individuals may have
Eliminate conflicting direction from Functional Management
Maximize use of uncompensated overtime
Force Functional Departments to meet schedule and budget commitments
Complete integration tests as quickly as possible
Program #2 - How to Get Back On Schedule
Design Production test set to be the same as the flightline test set - eliminates one test set type
Schedule CCA design so same CAD designer does them all, sequentially, to reduce training required to incorporate our unusual customer requirements
Use BFM to drive display panel for Human Factors testing to remove risk early
Assign two junior engineers to assist XXXXXX and YYYYY
Investigate Subcontracting the ZZZZZ assembly in its entirety due to resource constraints.
Program #1 plan is all about commitment (see Management Resolve). Are there really any solutions presented? Quantifiable improvements? It is all motherhood, and seems to blame the organization. Even if the organization is to blame, this slide will not help the project go any faster.
Program #2 plan actually has some ideas. They may make people uncomfortable, but at least they provide some actionable tasks that can be evaluated. Some might work. At least they are trying. If you were a manager in the audience, trying to figure out what to do, which slide would you rather see, and prefer to take action on?
If you don't have ideas, then find someone who does. Bring then in, and say: here are our biggest problems - what do we do?
Deadlining is sending the design onward based on date regardless of the actual state of completion. Deadlining is not strictly a method to improve the schedule or budget, because forcing a deadline does not typically yield improvements. Deadlining is useful to get a better understanding of the state of the design. If you have a designer who is dithering (unable to decide between competing approaches) , or the designer simply has not made the progress expected, you can flush this out by enforcing a deadline. If you find that a designer has not made the expected progress, then the cause is likely that the task is underpowered, resource wise. Find out what assistance is necessary and apply it.
If you proceed to the next step too early, deadlining will actually extend the overall completion date. This is due to the rework required as decisions are reversed or course corrections are implemented. If you want to wreck a job, tell everyone to go like hell before you have things figured out. This will destroy even the simplest job. Use deadlining sparingly, or you will end up with a big mess.