Vision
"Replace an enterprise information system that has been developed over the last ten years, to allow it to become stable on a modern architecture, to allow two new business units due to a split in the business to develop along their own paths, and to introduce new features that will take the business into the multinational domain."
Inception
The business wants to know how much such a system will cost. Although its vital for the entire business to be able to continue, it does make sense to get a grip on the costs of such a system, because with a vision like that, they are likely to explode. So the business has approached the IT department and asked for a conceptual phase to be carried out that includes analysis of requirements, conceptual analysis, migration plans and cost estimates.
Great, three months ago we started on the technical side. No requirements at this stage, other than the vision. We managed to put together the architecture though, with big caveats with regards to realisation based on actual requirements.
Hang on… shouldn’t we have stopped before writing about the architecture and waited for requirements? Well the project manager insisted we keep to the deadlines, so perhaps we could "put something together"? His budget, he can spend it how he likes (I get paid by the hour).
Two months ago, we completed the migration document. Again, because of a lack of requirements, it was largely conceptual, with lots of pretty flow charts to make migration decisions in the future become easier.
Two weeks ago, I went to my weekly meeting with the overall project manager, and he passed me seven sheets of "requirements". They were notes made by the 4 business analysts over a 6 week period. "That, Ant, is all we expect until the end of the year. I realise were late with them, but based on all your good work to date, I trust we shall have the estimates by 1st December?"
Elaboration…
Well, this one was actually dead easy to deal with. "Sure, I can tell you right now. It will cost you nothing. Because with what you have given me, I don’t have enough information to actually build anything."
That gut reaction wasn’t voiced, instead I took it to our account manager to get him to manage the customer a bit. His vast experience in the clients business sector was actually excellent. We went through the document, and decided 70% was out of scope as it belonged in existing systems. Some of it was light years ahead of what the business would be able to support, in terms of them being able to supply accurate data that these systems could run with. We decided the cost was in the range of 1 million, and 50 million. Its just a shame we are required to estimate within 30% so that the business can make a go/no go decision, after which we are bound by the 30%.
Transition
The outcome is that we shall have a workshop with the business analysts to be able to determine what is in scope and what is not. There after, we shall write some use cases by interviewing them (hang on, isnt writing use cases their job?). After that, we will grade the required functions with respect to each other, in terms of there technical complexibility and size.
The business can then apply their own weightings based on priorities, to decide what parts should be investigated further, and implemented like real projects, as opposed to these fairy projects from cloud-coo-coo land.
Lesson Learned
In the real world, we gather complete requirements that could be the basis of a legally binding document used to check off the deliverables. UAT is run against these requirements. If they are met, we have delivered successfully (in terms of funtionality – see the kitchen paper).
