The Monday status meeting is drawing a close. Doris the development manager was keen to start working through a file of resumes on her desk, Sarah the lead developer knew her pair Jo had started coding without her, Peter the product manager was on a flight to Madrid in a couple of hours, but Pat… Pat the Project Manager was a stickler for the agenda.
“And so,” concluded Doris, “the development team are now able to do weekly releases. All we are waiting on now is for Pat to tell us the customers have been informed and we will commence weekly releases – which means you can get your new features and fixes to customer even faster.”
“Actually,” Liz chipped in, “the new pipeline means we can do daily releases or even story releases. There is no need for us to batch work up into occasional releases.”
“Yes, yes, thats very good”, started Pat “however our clients have signed off on a roadmap and release plan that shows fortnightly releases, I’m negotiating with them for one week releases, some have agree. But right now we have a bigger issue to discuss…”
“Come on Pat” interrupted Peter “most of them will be only too happy to have their feature requests and fixes a bit earlier”
“Thats as maybe but there is a process we have to follow. Many of them run their own change management groups and the more frequent releases will cause them problems. In fact I know one change manager at a multinational who would rather we reverted to monthly release. But, as I was saying, there is a bigger issue we have yet to discuss.”
Doris and Liz gave each other known looks, they knew what was coming.
Pat’s face hardened, “When, ladies and gentlemen, when will we be done?”
And so an age old game commenced…
“What do you mean done exactly?” asked Doris.
“You know perfectly well what I mean by done Doris, how long have we worked together?” Pat paused. “Today is March 14, the project plan had us completing on January 31 which means we are nearly two months late. Luckily I’d built in four weeks contingency but we are now overdue and I have to raise an exception report and request an extension from the board. The first thing they will want to know is: How much longer? When will you be done?”
“Hang on,” Peter was rattled, “you agreed with using the contingency, we could have called it done when we made the January 28 release but you yourself agreed that we should continue, I distinctly remember you saying you saw ‘revenue enhancing’ opportunities in the backlog and that everyone expected the contingency to be used anyway.”
“Thats as maybe Peter, but we need a line in the sand, this can’t go on forever.”
“What do you mean can’t go on for ever?” asked Liz nervously, “Do you know something we don’t?”
“Liz, I’m privy to all senior board instructions and I can assure you there are no redundancies in the pipeline”, Doris, ever the diligent manager, knew Liz was had suffered and unexpected Christmas redundancy at her last employer and there were still scars.
“Well technically Doris, the whole team will be released back to the pool at the end of this project. However I fully expect them all to be immediately assigned to the next project which starts the day after this one ends.” Pat didn’t have Doris’ knowledgeable touch. “Which leads me to ask again, when will you be done?”
Liz was proud of their delivery pipeline: “If you are so keen to be done then we can be done on Thursday. The next release is scheduled for 3pm so we can call it a day then. In fact, if you want we could say we were done three days ago and start right now on the next thing.”
“Pat,” started Peter, “there are features in this project and features in the next project, its all the same product, frankly, I don’t care where you draw the line. Its all stuff to me, and the customers don’t care as long as they get their stuff.”
“Thats as may be, but we have a process to follow and its not about meeting a date its…”
“Not meeting a date? A minute ago you told us it was!” Like most of the programmers and testers Liz found Pat annoying.
“The date is important, Liz, because the later the date the greater the cost and the board have ordered us to reduce costs. When the new project starts we will have a new cost code and a new budget. So when, please, when will it be done?”
Doris was about to point out that it was all the same money no matter what code it was spent under but Liz got in first.
“How much money have we left? Lets just keep coding till we run of money.”
“Liz, I repeat, we have to cut costs, that will not cut costs.”
“Then why don’t we pick up the remaining features and put them in the next project then?”
“Liz, that is amoral! That would hit the next project with scope creep before it starts, it would increase the costs and risk it not hitting its deadline.”
“But Pat, the next project can meet any deadline because it will release weekly. When we run out of time or money we just call it done. It is all a question of what Peter prioritises.”
At the mention of his name Peter felt he needed to intervene: “Pat, really, what do you mean by done? If its date then Liz is right.”
“Peter, there were certain promises made about what was to be delivered in this project.”
“Yes Pat, and we’ve met them.”
“No we haven’t.”
“Do your mean the features the McAnderson consultants put in the original BRD? The ones that never even made Should Have list, and which I dropped the day I was appointed 12 months ago?”
“No, not them, but I can quite clearly see a, what do you call it, ‘backlog’ of work to be done in the Pira tracking system.”
“Actually, Pira is out of date, we don’t keep it up to date” chirped Liz
“Well you should, its in your role and responsibility document Liz, I think it quite specifically say Team Leader should…”
“OK, OK, there is work to be done” agreed Peter, “but… it is low value work we only mark it as Must these days because Should is full of rubbish. I’m more than happy to de-scope it, there is much more valuable work right at the start of the next project.”
“I would also point out,” continued Peter, “that all the remaining backlog is work that was added after the project began, what you call scope-creep. If you just look at the work McAnderson identified – and which I didn’t remove – then we were done six months ago.”
“Peter, its not my job to decide what is in or out, that is up to you and Harry the CEO, my job is to manage getting it done. So I repeat, when will you be done?”
But Doris was on the war path: “Actually Pat, it is my job to manage the development work, and I have to ask you again what do you mean by Done?”
“You don’t mean date because you extended the date and could request an extension again. On the other hand we could be done on Thursday or last Thursday. Date is a meaningless criteria.”
“You don’t mean when will the staff be released because nobody is being fired and they are all going to work on the same code base and product, in the same office, the next day.”
“And you don’t mean scope, the ‘what are we building’, because McAnderson gave us the wrong stuff to start with, everything they asked for has either been done or cancelled. Peter is happy to move work to another project and even happier to dump stuff altogether.”
“And if, heaven forbid, we were seeking to maximise value then we would immediately jettison everything left in this project and start the next one now because all the remaining work has less value than 80% of the next project.”
“So Peter, before you ask anyone ‘when will it be done’ again, can you please explain just what you mean by ‘done’ ?”
Sometimes the obvious isn’t so obvious, readers of a similar age to myself may well remember the scene in Flash Gordon where on of the baddies says “What do you mean, Flash Gordon approaching?” What do you mean, Done?
| Reference: | What do you mean… Done? from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
good effort.