I just got sent this brilliant little parody of the creative and development process involved in redesigning the Stop sign. It made me laugh, but it also rang so true that it made me a little uncomfortable. I think it does an excellent job at pointing out the dangers of not nailing down your project plan, and more to the point, your project goals, before you start your build.
I would stop at this?
A project is usually considered a success if the requirements of the stakeholders are fulfilled. It’s true. Who else is going to give you grief over it? When starting a new project, you need to determine who these stakeholders are before you do anything else. A stakeholder is anyone who has a vested interested in the end product. Along with the project sponsors, the project team, content contributors, end-users, managers, and financial controllers can all be stakeholders. Nothing derails a project like a stakeholder being included late in the piece – they almost always want to stick their oar in and bugger it all up.
It’s happened to me a few times, or should I say, I have let it happen to me a few times. I have worked on a stop sign! (…metaphorically speaking). People who for one reason or another weren’t originally considered important in terms of defining the goals of the site, are included into the mix at a later date, and understandably they usually try to make some impact on the project. And as your profit margin diminishes, you are left sitting there whimpering, “I am a good person – why is this happening to me?” Step one of any new project is to make a full list of the stakeholders, and get it signed off by the sponsor.
When you are making your project plan it is important to make sure your stakeholders have as much input as possible to get clear list of goals to form the basis of your plan.
Ensuring the goals of the stakeholders are defined, realistic, documented, and then managed, will help you avoid leaving yourself open to… scope creep (*shudder*). Also, in making this list you will have to resolve any conflicting goals amongst these stakeholders. Better to do it now that half way into your build. You’ll also gain a decent idea of what criteria will be used to judge the success of the project. Once these goals outlining what is expected at the end of the project have been finalised, then get that signed off too.
Now that you’ve got the goals for the project nailed down, you can push on and write your deliverables, and development timeline, sort out your project team, and all that other fun stuff, knowing that as far as requirements go, your arse is covered.
