Project Planning Services:
In recent years, it has become fashionable to assert that “computer software projects are really different.” “They play by a different set of rules.” “To be successful, we have to be ‘agile’ and ‘extreme.’ ” (Whatever that's supposed to mean...)
“Bunk!”
A computer is incredibly powerful, but it's only a machine. Furthermore, a computer program is one of the most intricate things yet devised. A successful, smoothly-operating piece of computer software is actually “a hundred thousand details working in harmony.” The only possible way to achieve that result, on-time and on-budget, is through meticulous project planning and management.
Webster's® Dictionary defines the term “meticulous” in this way: “Taking great care to get every detail correct; working thoroughly and with precision.”
This is the key to project success. A digital computer is, by its very nature, able to perform its tasks correctly only if “every detail is correct.” It's just the nature of the beast. Therefore, no matter how “hard-working” (or “agile” or “extreme”) your development or deployment effort might be, your efforts will be successful only if “every detail is correct.” Nothing else ... nothing less ... will do.
“Precise” does not mean “slow.” Quite the opposite. In fact, precision achieves greater sustainable completion times and consistently higher product quality than any other approach. Team efforts are not wasted, and valuable time is not lost. A computer software project typically involves the simultaneous work of many people ... developers, trainers, quality-assurance, marketing, executive ... and at any one moment in time, everyone's at a different point in their respective piece. Therefore, everyone must be working toward the same goals in complete confidence that they understand (correctly!) the eventual nature of the completed whole. Only in this way can be sure that, in the final set of software instructions that is eventually deployed to the computer, “every detail will be correct.”
The manufacturing trades have a very simple term they use for any “product of hard work” that doesn't go into a final, usable, saleable product. They call it ... scrap.
“Scrap.”
Not a pleasant word, is it? “Agile” and “extreme” sound like hoo-hah favorable qualities, like a bases-loaded grand-slam at the bottom of the ninth. Like the last bag of popcorn in a hot-summertime movie. “Scrap,” on the other hand, doesn't. And, that's why we like it.
“Scrap” isn't risk... it's loss. It's Money that should have been in your pocket, but that is now gone forever. Loss that could have been avoided. It didn't have to be this way, and there's no excuses for it.
Manufacturers structure their development processes to minimize scrap and to control defects, being especially careful to test for and to control defects as early as possible in the assembly cycle. Scrap is looked-down upon in the worst possible way; it is never condoned or accepted.
Our project-management approach emphasizes the following key points:
-
Formal requirements-discovery:
The word “formal” also doesn't mean “slow and ponderous.” It just means, “formal,” in that you do it distinctly separate from the subsequent processes that depend on it. When you're determining what to do, and how you might go about doing it, you're at the one-and-only point where you can change direction easily without producing scrap. It's acceptable (and expected) to leave certain things “to be determined (TBA),” as long as you have sound reasons to believe that scrap will not be produced as a result.
-
Explicit goals and timelines, explicitly tracked:
Yes, you can predict how long something will take, if you have answered the necessary questions first. Your predictions might be right or wrong, but they will have been well-considered. They can therefore be adjusted and tracked. The factors which might impede progress toward the intended goal are thus anticipated as early as possible, and deviation is detected in time to take action.
-
Short-term delivery cycles and staged deployment:
Because of the complexity of any software-related task, it is usually desirable to deliver something before “everything” is completed. Therefore, delivery-cycles are most useful when they are short, and deployment is most advantageous when it is staged. Thus, a large project is broken down into a series of smaller ones which overlap. But there is still a long-term plan that arches over the several smaller ones, and the goals and objectives of each are re-evaluated on a regular basis.
-
Observation of short and long-run scrap rates:
It isn't good enough that your development efforts “arrive at the right place somehow.” If a developer has a clear idea in-advance of what he or she is doing, the progress of that source-code module toward eventual completion is steady. But if those ideas are ill-formed, as in “making it up as you go along,” that shows-up in the source code history too. These inefficiencies can be squeezed out. They're also an easy-to-get-to short term assay of how confident your own programming team actually is its own progress toward the stated goals, and how certain they are of those goals in the first place.
The purpose of such a short-term “scrap rate” measure isn't to villify your employees, of course. Instead, we find that it's a fairly-objective measure of how well-illuminated your corporate target actually is. When the short-term goal is clear, the arrows hit the target consistently and they fly straight to it. When it's not, “it's a shot in the dark.” This way, you can recognize the problem swiftly enough to take corrective action.
-
Communication, communication, communication:
Enough said.
If you'd like to know more about our professional project-planning services, please contact us.