Archive
Ya Gotta Use This!
It’s interesting when people come off a previous project and are assigned to a new, in-progress, software development project. Often, they demand that their new project team adopt a process/procedure/technique/design/architecture (PPTDA) that they themself used on their previous project.
This can be either good or bad. It can be good if (and it’s a big IF) the alternative PPTDA they are promoting is actually better than the analogous PPTDA currently being employed by the new project team and the cost to integrate the proposed PPTDA into the project environment is less than the additional benefit it brings to the table. It can be really good if the PPTDA has been proven to “work” well and the new project hasn’t progressed past the point where an analogous PPTDA has been decided upon and weaved into the fabric of the project.
On the other hand, a newly proposed PPTDA can be bad in these cases:
- The new project team already has an equivalent PPTDA in place and there’s no “objective” proof that the championed PPTDA really does work better.
- The new project team already has an equivalent PPTDA in place and there’s “objective” proof that the championed PPTDA really does work better, but the cost of social disruption to integrate the PPTDA into the project isn’t worth the benefit.
- The new project team doesn’t have an equivalent PPTDA in place yet and the championed PPTDA has “somehow” been proven to be better than other alternatives, but adopting it would require changes to other well-working PPTDAs that the team is using.
Because there’s a bit of subjectivity in the above list and “rank can be pulled” by a so-called superior in order to jam an unworthy PPTDA into a smoothly running project and muck up the works, be wary of kings bearing gifts.
Armed And Ready
How much technical acumen does a project manager need to have in order to effectively manage a software-intensive product development effort? Are Spreadsheet, Gannt chart, PERT chart, EVM, Microsoft Project skills, and a golden certificate from schools like the vaunted PMI the only tools needed to lead a multi-disciplined, technical crew of engineers to so-called victory? I think not, but you may think differently – especially (and understandably) if you’re a project/program manager.
I think effective technical project managers are rare and they sprout from the trenches of one or more of the technical disciplines: software, hardware, test, and systems engineering. Wrestling with technical problems in the mud while under schedule pressure from multiple managers to keep costs down and to deliver quality promptly is the hazing experience needed to appreciate both the financial and technical aspects of a project or program. It may seem that project and program managers are under pressure themselves from executives above them in the command and control hierarchy, but unlike the dudes at the bottom of the food chain, they can easily pass the buck when financial and technical goals aren’t met. Who do ineffective BMs pass the buck to when the execs in the heavens demand accountability for poor project performance (usually way downstream after project execution has been supposedly progressing splendidly)? Why, the dweebs in the cellar of course.
“You have to know a lot to be of help. It’s slow and tedious. You don’t have to know much to cause harm. It’s fast and instinctive.” – Rudolph Starkermann
Cranking fat heads off the project management education assembly line and arming them with the necessary but insufficient skills to lead technically smart people into the raging battle against complexity is like arming firefighters with squirt guns to put out a 5 alarm fire. All it does is perpetuate the illusion of control and prep the graduates for moving higher up on the Plan-Watch-Control-Evaluate ladder – even though they don’t have a clue as to what they’ll be planning-watching-controlling-evaluating. But hey, I like to make things up and I’m not fit to lead anything, so don’t listen to a word I say 🙂
Plan, Plan, Plan…. Blah, Blah, Blah.
Preface
People followed Martin Luther King of their own free will because he had a dream, not a plan. – Simon Sinek
On the other hand, know-it-all business school trained weenies will profess (in a patriachical and condescending tone):
Failing to plan is planning to fail – Unknown
Irrelevant Intro
When I started this relatively loooong blarticle, I had no freakin’ idea where it would go but I followed where it led me. Led by the unknown into the unknown – it was the keystone cops leading the three (nyuk nyuk nyuk) stooges (whoo, whoo, whoo, boink, plunk, pssst!).
As usual, I didn’t have a meticulously well formed plan for this time-waster ( <- for you, heh, heh) in my fallible cranium and I made many mid-course corrections as I crab-walked like a drunken sailor toward the finish line. Hell, I didn’t even know where the freakin’ finish line was. I stopped iteratively writing/drawing when I subjectively concluded that….. tada, “I’ve arrived!”. Such is the nature of exploration, discovery, and exposition, no? If you disagree, why?
Pristine Profile – Full Steam Ahead!
The figure below shows the shape of a pristine, planned, cost vs time profile at “project start” for a long term, resource-intensive, project to do something “big and grand for the world”. Some one or some group has consulted their crystal ball and concocted a cost vs schedule curve based on vague, subjective criteria, and bolstered by a set of ridiculously optimistic assumptions and a bogus risk register “required for signoff“. To coverup the impending calamity, the schedule has been enunciated to the troops as “aggressive“. BTW, have you ever heard of a non-aggressively scheduled big project?
It’s interesting to note that the dudes/dudettes who “craft” cost profiles for big quagmire projects are never the ones who’ll roll up their sleeves, get dirty, and actually do the downstream work. Even if the esteemed planners are smart enough to actually humbly ask for estimates from those who will do the work, they automatically chop them down to size based on whim, fancy, and political correctness. <- LOL!
Typical Profile – Bummer
The figure below shows (in hindsight) the actual vs planned cost curve for a hypothetical “bummer” project. The project started out overestimated (yes, I actually said overestimated), and then, as the cost encroached into uncomfortable territory, the plan became, uh, optimistic. Since it was underestimated for “political reasons” (what other reason is there?), but no one had a clue as to whether the plan was sane, no acknowledgement of the mistake was made during the entire execution and no replanning was done. The loss accumulated and accumulated until end game – whatever that means.
Crisis Profile – We’re Vucked!
The figure below shows (in hindsight) the actual vs planned cost curve for a hypothetical “vucked” project. Cost-wise, the project started out OK, but because it was discovered that technical progress wasn’t really, uh, technical progress, bodies were thrown onto the bonfire. Again, the financial loss accumulated and accumulated until end game – whatever that means.
Replan Profile – Fantasy Revisited
The figure below shows (in hindsight) the actual vs planned cost curve for a hypothetical “fantasy revisited” project. Cost-wise, the project started out OK (snore, snore, Zzzzz), but because it was discovered that technical progress wasn’t really, uh, technical progress, bodies were thrown on the bonfire. But his time, someone with a conscience actually fessed up (yeah, some people are like that, believe it or not) and the project was replanned in real-time, during execution. Alas, this is not Hollywood and the financial loss accumulated and accumulated until end game – whatever that means.
Iterative, Incremental Profile – No Freakin’ Way
Alright, alright. As everyone knows, and this especially includes you, it’s easy to rag about everyone and everything – “everything sux and everyone’s an a-hole; blah, blah, blah…. aargh!”. What about an alternative, Mr. Smarty Pants? Even though I have no idea if it’ll work, try this one on for size (and it’s definitely not original).
The figure below shows (in hindsight) the actual vs planned cost curve for a hypothetical “no freakin’ way” project. But wait a minute, you cry. There’s only one curve! Shouldn’t there be two curves you freakin’ bozeltine? There’s only one because the actual IS the planned. This can be the case because if the planning increments are small enough, they can almost equate to the actual expenditures. At each release and re-evaluation point, the real thing, which is the product or service that is being provided (product and service are unknown concepts to bureaucrats and executive fatheads), is both objectively and subjectively evaluated by the people who will be using the damn thing in the future. If they say “This thing sux!”, its fini, kaput, end game before scheduled end game. If they say “Good job so far! I can envision this thing helping me do my job better with a few tweaks and these added features”, then it’s onward. The chances are high that with this type of rapid and dynamic learning SCRBF system in place, projects that should be killed will be killed, and projects that should continue will continue. Agree, or disagree? What say you?
This hypothetical project is called “No Freakin’ Way” because there is “no freakin’ way” that the system of co-dependent failure designed and kept in place by hierarchs in both contractor and contractee institutions will ever embrace it. What do you think?
The Best Defense
In “The Design Of Design“, Fred Brooks states:
The best defense against requirements creep is schedule urgency.
Unfortunately, “schedule urgency” is also the best defense against building a high quality and enduring system. Corners get cut, algorithm vetting is skipped, in-situ documentation is eschewed, alternative designs aren’t investigated, and mistakes get conveniently overlooked.
Yes, “schedule urgency” is indeed a powerful weapon. Wield it carefully, lest you impale yourself.
Meta-test Tools
A meta test tool ties together other lower level workhorse test tools in one place. Users interface with a meta test tool to launch and control the underlying system tool set that exercises the system under test. However, if you don’t have any low level test tools (out of dumbass neglect or innocent ignorance), a meta test tool is useless. But hey, the user interface and the camouflage it generates look good.
Undiscussable Unfairness
Assume that two similar projects are underway at your company. Also, assume that one of the teams is encumbered by a heavyweight process and the other is given a blank check to do as they please – no processes or procedures to follow, no external reviewers, no forms to fill out, no design or maintenance documentation to be generated. Would you confront management about the inequity? If so, why would you do something so stupid? Don’t you think the dudes in charge know what they’re letting happen? Don’t you think they would be pissed at you for pointing out the obvious but undiscussable stank of unfairness in the air?
I think perfect objectivity is an unrealistic goal; fairness, however, is not. – Michael Pollan
Breakfast Interpretation
While e-conversing with a colleague the other day, I used the following quote that encapsulates the chicken and pig story:
In a bacon and eggs breakfast, the chicken is involved but the pig is committed – Ken Schwaber
Surprisingly (it’s surprising because my colleague isn’t a member of the management guild), my infallible and self-righteous peer castigated me with a retort of “that’s inappropriate!”.
Dude, gimme a break. You see, just because the quote was created by a semi-famous software dweeb to belittle BMs, it doesn’t have to be interpreted that way. It can be interpreted as the exact opposite:
“managers who decide to provide financial backing for a project have more skin in the game than the engineers who spend the money – because if the project fails, the pecuniary loss is pinned on the manager by his/her manager(s)“.
This interpretation certainly has as much validity as it’s polar opposite, no?
Nevertheless, when I did utter the quote, I was using it to convey Mr. Schwaber’s original intent. Bad dog – as my colleague was quick to point out. He seems to delight himself whenever he clearly points out how stupid I am – which is often. Gotta love pumping yourself up at the expense of others. I should know, cuz I do it all the time. Mooo hah hah hah! Bad dog!
Buy this poster at motivatedphotos.com. Post it on your cubie wall – if you dare.
Thinking Is Not Allowed
I’m not very good at flying by the seat of my pants during encounters with bozeltine managers who demand answers to complex questions on-the-spot, in real-time. When I spontaneously find myself in those situations, I tend to get flustered and make stuff up (more than I normally do (which is a lot)) to appease those in authority.
Rather than calmly saying “(please) let me think about it and get back to you“, I tend to cave and pull some stanky chit out of my arse. Maybe it’s because of the perception that “thinking” isn’t allowed? Maybe it’s because of the expectation that everyone should be perfectly all-knowing? If BMs were conscious of their irrational behavior when they ask for information, then they’d say “please think about it and get back to me“. But then, they wouldn’t be BMs. They’d be, heaven forbid, empathetic leaders.
Buffer Gone Awry
Assume that you’re a manager enveloped within the predicament below. On a daily basis, you’re trying to coordinate bug fixes and new feature additions to your product while simultaneously getting hammered by internal and external customers with problem reports and new feature requests.
In order to reduce your workload and increase productivity, your meta-manager decides to add a “buffer” manager to filter and smooth out the customer interface side of your job. As the left side of the figure below shows, the hope is that the team’s increased productivity will offset the doubling of overhead costs associated with adding a second manager to the mix. However, when your customers find out that they now have two managers to voice their problems and needs to, the situation on the right develops: your workload remains the same; you now have an additional interface with the buffer manager (who has less of a workload than you); the overhead cost to the org doubles. Bummer.
Iteration Frequency
Obviously, even the most iterative agile development process marches forward in time. Thus, at least to a small extent, every process exhibits some properties of the classic and much maligned waterfall metaphor. On big projects, the schedule is necessarily partitioned into sequential time phases. The figure below (Reqs. = requirements, Freq. = frequency, HW = hardware, SW = software) attempts to model both forward progress and iteration as a function of time.
If the phases are designed to be internally cohesive, externally loosely coupled , and the project is managed correctly, the frequency of iteration triggered by the natural process of human learning and fixing mistakes is:
- high within a given project phase
- low between adjacent project phases
- very low between non-adjacent project phases
Of course, if managed stupidly by explicitly or implicitly “disallowing” any iterative learning loops in order to meet equally stupid and “aggressive” schedules handed down from the heavens, errors and mistakes will accumulate and weave themselves undetected into the product fabric – until the customer starts using the contraption. D’oh!
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 