Staffing Profiles
The figure below shows the classic smooth and continuous staffing profile of a successful large scale software system development project. At the beginning, a small cadre of technical experts sets the context and content for downstream activity and the group makes all the critical, far reaching architectural decisions. These decisions are documented in a set of lightweight, easily accessible, and changeable “artifacts” (I try to stay away from the word “documentation” since it triggers massive angst in most developers).
If the definitions of context and content for the particular product are done right, the major incremental development process steps that need to be executed will emerge naturally as byproducts of the effort. An initial, reasonable schedule and staffing profile can then be constructed and a project manager (hopefully not a BM) can be brought on-board to serve as the PHOR and STSJ.
Sadly, most big system developments don’t trace the smooth profiling path outlined above. They are “planned” (if you can actually call it planning) and executed in accordance with the figure below. No real and substantive planning is done upfront. The standard corpo big bang WBS (Work Breakdown Structure) template of analysis/SRR/design/PDR/CDR/coding/test is hastily filled in to satisfy the QA police force and a full, BM led team is blasted at the project. Since dysfunctional corpocracies have no capacity to remember or learn, the cycle of mediocre (at best) performance is repeated over and over and over. Bummer.
Leave a Reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
Some customers contract the development paths and schedule that a project is to follow. So the “artifacts” their release dates are determined at the time the contract is signed. The process you are highlighting is a variation on the waterfall process.
Hi Ray,
I wasn’t trying to highlight any product development process, waterfall or otherwise. I was just trying to contrast two different ways of staffing projects over time; conscientious and continuous vs frenetic and discontinuous.
This ties in with my last post re: product vs project orientation. If you look at the system to be developed from a lifecycle viewpoint (one which understands that it’s a commitment/relationship rather than an event), then the first graph is a natural fit and customer satisfaction is much more likely than in the second case.
Lifecycle viewpoint, what’s that? 🙂 In dysfunctional orgs, short term beats long term every time.
I once worked somewhere where dysfunctional would have been an improvement:
* The business would produce weighty tomes describing in intricate detail the features they wanted, these were duly delivered to product managers.
* Said product managers would roundfile the requirements documents and produce their own version of what the business “really needed”, these were duly delivered to the development team.
* developers, upon finding the requirements unworkable, would deliver something approximating them to testers.
* testers, determining that all of the above parties were completely brain dead, would enter bug tickets to have the code changed to match what they decided the business “really needed”.
* after re-work, either testers or product managers would fail the ticket and enter something new.
* lather, rinse, repeat until everyone got tired enough to say “just push it”
* users reaction: WTF????
The way I describe it is “we didn’t have releases, we had escapes”
Sheesh. How could a place like that stay in business?
The short answer is, they couldn’t…it was a subsidiary of a larger company that underwent a huge round of layoffs and then was re-absorbed by its parent. There was no overcoming the double whammy of a legacy of poor service plus a truly horrid product (a “web app” of ASP + ActiveX controls that had become so bloated that it had to be hosted on Citrix…and no, I had no hand in the design of that!).
The interesting part of the story is that my boss there had finally sold a major re-work of the process about a year before the meltdown. We had made so much progress towards engaging our customers that as part of the re-org that brought us back into the parent company, we were made responsible for evangelizing our process to the rest of their development group.
I’m glad it turned out well for you.