Archive
Butt The Schedule
Did you ever work on a project where you thought (or knew) the schedule was pulled out of someone’s golden butt? Unlucky you, cuz Bulldozer00 never has.
Product Lifetime
The UML state transition diagram below depicts the growth, maturity, and retirement of a large, software-intensive product. There are a bazillion known and unknown factors that influence the longevity and profitability of a system, but the greatest determinant is how effectively the work in the upfront “Develop” state is executed.
If the “Develop” state is executed poorly (underfunded, undermanned, mis-manned, rushed, “pens down“, etc), then you better hope you’ve got the customer by the balls. If not, you’re gonna spend most of your time transitioning into, and dwelling within, the resource-sucking “Fix” state. If you do have cajones in hand, then you can make the customer(s) pay for the fixes. If you don’t, then you’re hosed. (I hate when that happens.)
If you’ve done a great job in the “Develop” state, then you’re gonna spend most of your time transitioning into and out of the “Enhance” state – keeping your customer delighted and enjoying a steady stream of legitimate revenue. (I love when that happens.)
The challenge is: While you’re in the “Develop” state, how the freak do you know you’re doing a great job of forging a joyous and profitable future? Does being “on schedule” and “under budget” tell you this? Do “checked off requirements/design/code/test reviews” tell you this? Does tracking “earned value” metrics tell you this? What does tell you this? Is it quantifiably measurable?
Defacement
While browsing for blog post ideas, I felt a strong need to deface this Dilbertonian classic with BD00 graffiti:
Mostly True
“Adding people to a late project makes it later” – Frederick Brooks
If an underway project is perceived as a schedule buster (and it usually is if managers are thinking of hurling more bodies into the inferno) then this famous Brooksian quote is true. However, if the project’s tasks are reasonably well defined, loosely coupled, and parallelized to the extent they can be, then adding people to a late project may actually help it finish earlier – without severely degrading quality.
Alas, the bigger the project, the less likely it is to be structured well enough so that adding people to it will speed up its completion. Not only is it harder to plan and structure larger projects, the people who get anointed to run bigger projects are more likely to be non-technical managers who only know how to plan and execute in terms of the generic, cookie-cutter, earned-value sequence of: requirements->design->code->test->deliver (yawn). Knowledge and understanding of any aspect of the project at the lower, more concrete, project-specific, level of detail that’s crucial for success is most likely to be absent. Bummer.
It’s About The People, Stupid
Check out the chapter names in part III of a brand spanking new “Project Manager‘s Handbook“:
So much for valuing “people and interactions over tools and processes“, no? The closest the book comes to mentioning people is that the word “staff” is mentioned once and “resources” twice. And no, the first two parts don’t emphasize the importance of people either:
So, aspiring young project manager, it’s obviously all about you. All ya gotta do to be successful is mechanistically follow the infallible recipe; dot the i’s and cross the t’s. Fuggedabout developing trusting, helpful, two-way relationships with the people who will be executing your project work. It’s not important or even necessary. All you have to do is: develop the plan, “acquire the resources”, and push the “go” button. 1-2-3.
To be semi-fair, I haven’t (and don’t plan to) read the book. The author may indeed address the thorny issues associated with monitoring progress and product quality, guiding the effort, and ensuring the well being of the people so that they’re willing to do their best – but I doubt it.
Home Grounds
In Barry Boehm and Richard Turner‘s book, “Balancing Agility And Discipline“, they present the concept of the “home ground“. Agile and plan-driven (a.k.a. waterfall) software development methodologies each have their own turf where one is superior to the other for getting the job done within time, budget, and quality constraints.
As the figure below shows, the Boehm/Turner definition of “home ground” is based on 5 dimensions: personnel (experience/expertise), criticality, dynamism, size, culture.
At the origin of the 5 dimensional chart, where dynamism is high, culture is liberally open, project size is small, criticality of application is low, and the majority of the project staff is highly competent, agile approaches are more effective and efficient and efficacious. At the extremes of the 5 axes, plan-driven approaches are more effective and efficient and efficacious.
Do you think Boehm and Turner have got it right? Are there any dimensions missing from their model; like level of management humility, quality of management-knowledge worker relationships, quality of tools, quality of physical work environment?
Definition Of Done
When the definition of “done” for a software development project is solely based on allocated time and budget, it’s relatively easy to be perceived as successful. When the schedule and budget are exhausted: the work stops, the software is delivered/released/deployed, and victory is unequivocally declared. Whoo Hoo! As long as the software runs, regardless of its quality and usefulness, all is well – in the short run.
When the achievement of one or more difficult-to-measure, but meaningful, quality metrics is added as a third criterion to the easily measured time and budget metrics, the meaning of “done” becomes less vague and more realistic. That’s why it’s rarely done in practice.
Ya see, CLORGs and DYSCOs are full of themselves. By not measuring the things that matter for long term viability, they can stay infallibly full of themselves till the fit hits the shan.
Meet The FOCHers
FOCH == Frequency Of CHange
A Bum Rap
Middle managers often suffer from a bum rap. There’s pressure from above to meet schedule and cost, and there’s pressure from below to trade schedule and cost for quality. Since their bread is buttered from above, the likelihood of middle managers being able to deftly handle those conflicting demands equitably is low, very low. Ya can’t blame them for capitulating to the demands from above, right?
That’s All It Takes?
The MITRE corporation has a terrific web site loaded with information on the topic of system engineering. In spite of this, on the “Evolution of Systems Engineering” page, the conditions for system engineering success are laid out as:
- The system requirements are relatively well-established.
- Technologies are mature.
- There is a single or relatively homogeneous user community for whom the system is being developed.
- A single individual has management and funding authority over the program.
- A strong government program office capable of a peer relationship with the contractor.
- Effective architecting, including problem definition, evaluation of alternative solutions, and analysis of execution feasibility.
- Careful attention to program management and systems engineering foundational elements.
- Selection of an experienced, capable contractor.
- Effective performance-based contracting.
That’s it? That’s all it takes? Piece of cake. Uh, I think I’ll ship some parkas and igloo blueprints to hell to help those lost souls adapt to their new environment.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 