Engineering and IT Insight: Schedules for engineers
A missing or unrealistic schedule is a bad habit common to unsuccessful projects. Lack of experience in the project space can lead to ballpark estimates and schedule slippage. Zeno’s Project Paradox is that no matter how hard you work on a late project, it is never more than 90% complete. Ask any project manager of a late project, and they always say the project is 90% complete, even if they have spent 200% of the budget and are months, sometimes years late.
Dennis Brandl for Control Engineering
Math classes use Zeno’s Paradox to help teach calculus. Zeno of Elea (circa 450 B.C.) is famous for his paradox, the tale of a race between Achilles (the fastest man alive) and a tortoise. His paradox was that no matter how fast Achilles ran, he could never catch the tortoise because when Achilles ran halfway to the tortoise, the tortoise had moved and Achilles now had farther to run. It took the invention of calculus to disprove Zeno’s Paradox, but there is no advanced math that can disprove Zeno’s Project Paradox. Zeno’s Project Paradox is that no matter how hard you work on a late project, it is never more than 90% complete. Ask any project manager of a late project, and they always say the project is 90% complete, even if they have spent 200% of the budget and are months, sometimes years late. Eventually these projects are declared “complete,” even though they have delivered only 90% of the required functionality.
A bad habit in unsuccessful projects is a missing or unrealistic schedule. Once people recognize the problem, the project is often unavoidably stuck in Zeno’s Project Paradox.
You know if your project has this bad habit if (a) there is no firm schedule, (b) no one knows the real schedule, or (c) the schedule seems to slip by at least one week for every two calendar weeks. Once you get into this situation, it is nearly impossible to complete the project on time, within budget, and with the required functionality.
One bad situation is to have no firm schedule. This is often the case when the project team has no experience in the problem space. Without any experience, there is no way to know what tasks are needed, how to estimate the effort required for the tasks, and how to sequence the tasks. When this happens, the project team will usually just provide a “ballpark” estimate of the cost and schedule and then jump right into the project. Only later, when a significant fraction of the project budget has been spent and there is no indication of progress, will the alarm bells go off. Then everyone will scramble to build a new schedule but, because it is not clear what has been done and what remains to be finished, the new schedule will usually be wrong and wildly optimistic. Projects without firm schedules can succeed, but only because of almost superhuman effort on the part of the project team, and, unfortunately, this is not a reproducible method for success.
If you have a schedule, but it seems to be more secret than the Coca-Cola recipe, then your project has a major bad habit. Schedules are targets that allow people to plan their work and pace themselves to complete the work without burnout. Professional runners would not participate in an event in which the distance is not known until they reach the finish line. Runners use the race distance to pace themselves, so they can finish the race and not burn out or run more slowly than they should. Engineers are the same way with automation projects; they need to know how big the project is so they can pace themselves to complete it on time and within budget, and meet the required functionality. When the project schedule is not widely available and is only visible to and used by top management, then it has little value for the project. If the schedule is not known, then it is unreasonable to judge team member performance against this hidden standard. If every team member does not know where the project schedule is, how to access it, and how to read it, then your project is in trouble. The schedule should be prominently posted on paper or in a project Wiki and available for all to see.
If your project schedule seems to slip by at least one week for every two calendar weeks, don’t believe that eventually you will catch up. This is not Zeno’s Paradox, where the series converges to a finite value. This is the early stage of the Zeno’s Project Paradox, where the end point will always be a little out of reach. This is a bad situation to be in. You have a schedule, everyone knows the schedule, but everyone seems to be missing the schedule deadlines, especially the critical path deadlines, and no one seems to know why the schedule keeps slipping. Another way to recognize this situation is when the schedule slips and the critical path activities seem to change weekly.
This situation happens when the project team understands the importance of a schedule but has no experience in the problem space. It may also occur when the schedule is imposed on the project team without regard to feasibility. A key phrase to remember is “a schedule imposed becomes a project disposed.” The schedule must be developed with knowledge of the problem space, knowledge of the available technology, agreement by the engineers and experts about the feasibility of the schedule, and agreement by the project owners on both the minimum and desired functionality.
Schedules are important no matter what project methodology you are following. In a waterfall method (requirements, design, testing, and deployment) the schedule provides the project mile markers. It allows project members to see if they need to speed up or apply more resources. If you are using an iterative methodology, such as SCRUM or Agile, then the schedule acts as a lap-counter. Each cycle through the requirements-design-testing-deployment phase serves as a check on the project’s progress and advancement to project completion.
Don’t allow your project to fall into Zeno’s Project Paradox. Avoid the paradox by building a schedule using knowledge of the problem space and available solutions, making the schedule know to all team members, having buy-in by the team members, and tracking achievement against the schedule. Following these rules will help you get past the “90% complete” phase in your automation projects.
- Also read:
IT and Engineering Insight: Control architecture, who needs it? - If you have a large control software programming project and no control system architect, small changes can lead to dead ends and bad decisions.
IT and Engineering Insight: Seven habits of unsuccessful projects - Understanding if you are in an out-of-control IT project is important. Here are some traits of failing or soon-to-fail projects. If you have three or more of these project attributes, you need a project "reboot."
Production line remote monitoring - Engineering and IT Insight: Automation engineers spend a lot of time just getting to the right place to identify and fix problems. The IT solution to this problem is based on VNC, or virtual network computing.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.