The software development process is complicated and not easy to explain to senior managers. If you have only five minutes to get some key points about the software manufacturing process across to senior people try this.
Do you buy a ticket for the Lottery every week? Well, this week you're rash - you invest your pound and buy a ticket.
And at last your numbers come up! You haven't won a fortune though, only a million pounds/dollars/euros. Clearly you now have a problem: deciding what to do with the million.
You consider many high level solutions to the problem: buy a small island; retire; buy a yacht; invest it; etc. But in the end you decide the outline solution to the spend-a-million problem will be to have a house architect designed and built.
Your Project Definition Document (PDD) says: Problem - spend a million; Outline Solution - design and build a house; Sponsor - you; Users - your family.
You and the family spend many happy evenings defining your requirements. Now, secretly you have always wanted seventeen children - which you can now afford - so the requirement is for a house with 17 small bedrooms.
If you now approach a useless architect he will design a house for you which has 17 small bedrooms - and nothing else. Kitchen? You didn't ask for a kitchen. Bathroom...?
But a good architect will work collaboratively with you during the design step and take you back to your fundamental requirement which is to house the tribe, and working together you will design a house with a kitchen, bathroom, living room and perhaps 9 double bedrooms. Ideally you would perhaps have involved the architect in your requirements analysis sessions so that he could have got a good feel for what sort of house you're really after and so he could guide you away from asking for things that would be impossible or ridiculously expensive to build.
Half way through the design step the architect says to you: "Look what arrived in my post this morning, it's a brochure advertising solid gold bath taps. Aren't they lovely?" You take one look and it's love at first sight: you must have solid gold taps throughout the house!
"But," the architect says. "They are £/$/€50,000 a pair!" In that case, you decide, you will change your requirements: you will only have two children and instead spend the money on solid gold taps throughout the house. Doubtless a wise decision.
This happens in all IT projects: when the business users see what is possible technically they say: "ahah, we didn't know that was possible, we'll change our business process to exploit that." You need to allow for this kind of thing in the design step plan.
A high-tech architect will now put the draft house design into a virtual reality simulator. You will don the headset and walk around your house in virtual reality, getting a feel for what it will be like when eventually built.
Even if you get this VR simulation the architect will still produce a document for you with all the floor plans, which way the doors open, whether the taps will be solid gold or gold plated, etc. And once you have signed off that document that will be the house you're going to get. If it was your house and your money would you pay attention to that document before signing it? You bet! Unfortunately users in IT projects don't have quite the same incentive to scrutinise the User Functions Design document. In an IT project whose job is it to make the users apply their minds to reviewing the UFD properly before signing it off? Once again you've guessed it - the project manager.
The techies now get to work on the technical design of your house. Would you be interested in knowing how many British Thermal Units your boiler was rated at or the Newton value of the concrete blocks? You wouldn't.
In some IT projects IT produce a design document that contains the user functions design and the technical mumbo-jumbo design muddled together and then ask the users to sign it off. Result: befuddled users. Don't do it. Keep the User Functions Design document to those things the user needs to know and put all the techie stuff in a separate IT Technical Design document.
Back to our house. Half way through the technical design step the builder calls you and says: "you know we promised you a twelve foot wide living room? Could we make it 4 metres instead, which is thirteen feet one and a half inches? No extra cost." You ask why. "Well, joists all come in metric sizes now, so it's actually cheaper to build it 4 meters than 12 feet."
You might say: "Great! More space no cost? Go for it." Or you might say: "No, the living room must be twelve feet wide because all my Persian rugs are 12 feet wide."
The same happens in IT projects. IT discover it would be much cheaper if two input screens were combined into one - would the users like to agree to such a change?
The builder builds the house and the builder checks that it all works in accordance with the "User Functions Design" document plus any agreed and signed off changes. How would you feel if, house nearly finished, the builder in the middle of winter invited you to come and live in the house on a trial basis to test whether the central heating works or not? You wouldn't do it, would you? But for some strange reason users of IT projects seem happy enough to test half-baked IT systems.
But your builder is a professional and gets the house right. You then move in and live happily ever after.
Two things are obvious about the house-building project which are equally true in software projects but not equally obvious in software projects. Firstly, in the house-building project where would you and your family be primarily involved?
In the Technical Design step your involvement is minimal (though you do need to be available to consider changes proposed by the builder), ditto in the Build and Test step and the Acceptance step should be just a formality. (Would you say; "ah, now I see it built what I actually wanted was..." Don't think so.)
In the house-building project you will be heavily involved in the project definition, requirements and the design steps. Exactly the same should be true for users in IT projects and for the same reasons. Though you do have a fairly major sub-project that runs in parallel with Technical Design and Build: the House Move sub-project. Getting bills and bank statements redirected, organising the removal men, etc. Just like the user implementation activities in an IT project.
Secondly, at the design stage you'd like a window moving three feet to the left. How much will the change cost you? Not very much, it might even be free. But when the house is nearly finished what will that same change cost you? A lot of money! The same is true in software projects but nothing like so obvious.
The analogy makes a couple of things very clear to senior managers: why they should invest their user staff in the early stages of the project; why they should ensure the design is checked very thoroughly; and why they should not change their mind about the requirements having signed off the design. Suddenly it's all rather obvious.
Designing and building houses is in many respects very similar to designing and building software and the analogy can help to de-mystify the software development process.
Though this notion that we should explain to senior business managers what software development projects are all about does rather overlook the Medieval Monk tendency amongst some IT suppliers. Medieval monks didn't like peasants to be able to read as this enabled them to acquire knowledge and thus potentially challenge some of the nonsense with which the monks held them in thrall. For similar reasons some who later translated the Bible into English were burned at the stake (e.g. by Henry VIII): can't have the peasantry challenging our interpretation of the scriptures, bang would go our power! Interestingly when Henry VIII later dissolved the monasteries he commissioned an English translation of the Bible exactly for that reason - to erode the monks' power.
Projects are all different. Decide what's the most appropriate way to do yours, make sure the team understand it and
enlighten senior managers.
...next
Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
This book must not be copied either as is or in modified form to any website or other medium
www.hraconsulting-ltd.co.uk
Home Sitemap Contact Us Project Management Articles Project Management Book