The Screwpole Emails - Project Types
Episode 2 in our everyday story of project sabotage.
By following his demonic uncle Screwpole’s advice, devil initiate Mugwort has had much success in eroding the quality of his victim’s payment engine project and has written an excited e-mail to his uncle. Here is Screwpole’s reply…
To: Mugwort From: Uncle Screwpole Subject: As promised, how to categorise projects… [spam?]
My dearest Mugwort,
You may recall I promised to advise you on the types of projects you will surely encounter. You must arm yourself with as much knowledge as you can on how to sabotage these projects. If you fail to heed my advice, the Infernal Hierarchy will surely force you to spend an eternity making promotional scratch-cards to put in magazines!
So pay attention: in the world of software projects, there are two aspects you must always consider. First, the experience of the team. This represents the competence of its members; modified by the number of times they have carried out projects of a similar nature. The other is the completeness of vision. This is how well the team understands the project requirements; and also includes the customers’ ability to express what they really want (always try to persuade them to design the technical solution rather than just to ask for what they need).
Building a pre-fabricated house
Your victim’s first – successful - project [I do hope, but not a lot, that you’ve recovered from being slobbered upon by the giant, disembodied floating mouth] was like building a pre-fabricated house, as I pointed out in my last correspondence. The team were familiar with the 25th database plug-in they were building and knew exactly what to do, with a very clear vision.
In this type of project, the goals are to deliver better, faster and cheaper than before. Most senior managers wrongly believe that all projects are like this. [Keep them ignorant of the truth and these same senior managers will be your clockwork toys of IT destruction – wind them up and send them flailing into other projects!].
For these projects, you must at all costs stop your victim from using Gantt charts, PERT analysis, Critical Path Analysis and Earned Value Analysis. These might make him focus on the dependencies, interfaces and costs of these projects.
Publishing a newspaper
Imagine if you can, dear boy, the morning meeting at a newspaper. The editor has a clear vision of the day’s issues [Really? – Ed] and allocates stories to individuals. The staff are experienced journalists in their fields, and do not need to be told how to write articles [Well, up to a point, Lord Copper – Ed].
In projects of this type, there are four danger signs for you to look out for: frequent planning, a deep trust of the staff, the removal of barriers, and a reduction of critical resources.
It is especially dangerous, Mugwort, if you find your victim creating a detailed plan for a short period (just a few weeks at most), observing progress and amending the plan constantly. Instead, try to bend the victim’s gaze far into the future and get him to amend his Gantt charts constantly, and for many weeks in advance. [In my next email, I’ll share a few trade secrets on how to sabotage time estimates…]
In many ‘newspaper’-style projects, only certain people can do certain types of work – insist that this continues! Heaven forbid [and it would make our jobs easier if it did] that people should identify single experts and other critical resources, and take steps to remove these bottlenecks.
Take note of these particular projects. You will meet these often, as most software projects are like this; even though most managers don’t realise it.
Voyage of discovery
Although many IT projects are like this previous type, frequently you will have projects which truly are “voyages of discovery”, and occasionally some will be dragged down into this state by staff inexperience. You can tell a ‘voyage of discovery’ when the manager has a very specific problem that neither he nor the team know how to solve.
I recall a project, many ages ago, where my victim needed to work out how to extract data from a legacy system. No one on the team had experience with this system; or, indeed, with the type of technology involved.
I am ashamed to admit, my lad, that the project was a success… well, I tried to claim, only a “seriously qualified” failure. My victim’s first step was to create ‘taskforces’ to explore the many options, and then he began a two-day “heartbeat”, in which taskforces reported back and refined their searches. These processes allowed them to time-box their costs and quickly evaluate and reject poor ideas.
In only two weeks, an apparently intractable problem had been solved. The manager swiftly moved back to a comfortable place. My place was not so comfortable. I spent the next eon sewing together tiny, sock-sized black holes to put inside washing machines.
To avoid such a fate, you must encourage your victim to plan and document in endless detail. Advise him never to discard ideas that are not working. Guide the team down the initial, wrong path. Remind them that, after all, they have spent so much time on it already...
In the dark place, everyone knows there’s a problem but no one has any experience of solving it. There’s no clearly defined vision and the team hasn’t delivered anything of this kind before. My fondest memory of a project like this was at a company with several CRM systems that were being merged into a unified whole. Fortunately for me, that was the only specification available.
Fortunately for you, it takes a very strong manager to navigate out of the dark place. The manager needs to identify a vision that delivers value; and then has to find a sufficiently powerful champion to support this vision. If it is approved, then it is possible for the manager to move the project forward and offer real benefit.
You should find it easy to avoid this “healthy” [ugh] situation. Obscure your victim’s vision and never allow a regular heartbeat to take hold. Your manager may try to spawn sub-projects of the ‘voyage of discovery’ or ‘newspaper’ variety to move the project forward - prevent this happening at any cost, by sabotaging senior management approval (point out how wasteful such “non strategic” efforts are).
Whisper in your victim’s ear that he should strive to solve the problem in a single impressive leap, rather than in a chain of small weaselling stages.
But enough lecturing for this week, my nephew. I must attend the second-hand soul auction – I need a quivering human spirit to scream at in the mornings.
I look forward to your next email, Mugwort. Do not let me down.
Phil Rice is CTO of software vendor Erudine
With acknowledgement to CS Lewis' "Screwtape Letters".
Sponsored: Benefits from the lessons learned in HPC