Planning for Success
As Web projects evolve from online brochures into sophisticated and dynamic tools so their development becomes harder to manage. Define what you need your project to do at the start of the process, and you can ward off disaster later on.
Managing the development of an online system can be fraught with risk. Too often management practice fails to measure up to the scale and complexity of the modern Web project. The key to securing success can often be found at the beginning of a project or project iteration. It is at this point that requirements are defined. In chaotic projects they often remain broad brush affairs. Vague requirements can cause irreparable damage to a project if they are not fleshed out before production commences:
- Relations with developers can deteriorate as requests to alter delivered work get out of hand. Informal requirements will lead to disputes sooner rather than later. Developers may dislike revisiting delivered code to add features that were not specified. Much worse for a project though are the accusatory and defensive tones that can creep into the relationship as vaguely remembered requirements discussions are forensically analysed.
- Budget and timescale balloon as unforeseen needs come to light. Features are often more complex than you imagine, and can hide additional fine-grained requirements. If you have not allowed for this you will face unscheduled development time. You will also suffer delays caused by the inevitable mails, calls and meetings needed to clarify or dispute requirements.
- Minor features can be over-produced, threatening the fulfilment of more important requirements. If requirements have not been prioritised, less important functions can be given disproportionate attention. Developers may spend more time than necessary on the feature at the expense of features that you may feel are more deserving.
- Quality Assurance is sacrificed in order to pack in all the functions required in time for your deadline. Once a project is nominally complete, it is good practice to allow time for testing, bug fixing and minor changes. If your project is overrunning it can be tempting to allow development time to continue right up until the delivery deadline. The loss of the Quality Assurance phase can transform a slick product into an embarrassing disappointment.
There are some simple things that you can do to avoid these pitfalls:
- Ensure that time estimates allow for a 'discovery phase' at the start. Planning is the most important part of your project.
- Look below the surface of your requirements. Every bullet point in your requirements list will imply other needs. Be as exhaustive as you can in defining these needs. Better to consider a frivolous need and discard it than to discover an unfulfilled requirement as your project nears completion.
- Ensure that your developers tell you how they interpret the detail of your requirements. Get them in and talk about each requirement in some detail. Ask them to consider implied needs that you may have missed. Write down your conclusions.
- Ask your developers to identify danger areas, and to provide worst case estimates.
- Ensure that time has been allowed for quality assurance and testing at the end of the development cycle.
Planning can feel like wasted time. You can spend weeks on a requirements phase, and only have documents to show for it. But paying proper attention to requirements will increase efficiency, improve outcomes and may one day save your project from disaster.
XHTMLEnhancements within budget They have always been very accommodating and flexible, and come up with dynamic solutions to enhance our site within our budget.
Sue Harley, Royal Lancaster Hotel
BGZ Courses We teach open source and open standard technologies. We aim to cover the detail of any topic we tackle, but also to reach beyond that to the principles that underlie the subject.