Professional PHP5 (Programmer to Programmer Series)
ISBN: N/A
EAN: N/A
EAN: N/A
Year: 2003
Pages: 182
Pages: 182
In almost every project of any scale, there are going to be change requests made by the client. Managing these changes is enormously important. You need not only to assess the commercial impact of any changes you make but also understand the enormous disruption that can occur through major changes to a well-entrenched software or systems architecture.
In this section, we look at some of the most common varieties of change requested by clients and the best way to handle each of them.
These are not only inevitable but should be actively encouraged. Your client will want to make changes to the specification you have produced, because it is almost certain that you will not quite have managed to hit the nail on the head first time around.
Collate any change requests together into 48-hour periods. Use a change management package such as Microsoft Project or MrProject (http://mrproject.codefactory.se) if necessary. Every 48 hours, incorporate the previous two days' changes into a new release of the specification and offer it back to the client.
Be sure to make the client aware of any requests that will for one reason or another prove unfeasible as soon as they are put forward.
If the client requests changes after signing off on the specification, you may have a problem on your hands. First, don't panic. You have the moral high ground. The client's signature on your specification is an affirmation that he or she was 100 percent happy with what has been produced. Should you feel the need to bill them for the change, you are, strictly speaking, within your rights to do so.
Before you make a decision, however, consult the rest of your team. Try to determine how far into the design and/or build phases your team has gone. Try to quantify in terms of work hours the kind of disruption that is involved in rewinding the process back to specification stage so that the requested change can be made.
If you can put a price tag on this work, it is worth making a judgment call as to whether it is worth passing this cost onto the client. It is normally considered to be in the interest of good client relations to show some grace and flexibility in these situations, unless they become a regular occurrence.
If you decide to proceed with the change, be sure to make it very clear to the client the time impact it will have, and come to an agreement concerning any revised milestones that the change may necessitate. Ensure that these your project team concurs and that the new timelines include a contingency margin.
Sometimes, a client can query the interpretation of a specification and request changes as a result. These queries are always difficult to manage. After all, you cannot accuse the client outright of simply being wrong. The best approach with these situations is to try hard to avoid them altogether in the first place by being as fastidious and specific as possible in your specification, avoiding ambiguity wherever possible.
When they do crop up, however, be prepared to negotiate with the client. Listen carefully to the client's concerns and endeavor to understand his or her point of view. Discuss with your team the time required to make the changes in question and then put them to a simple commercial test: in terms of cold, hard cash, is it worth arguing the point?
Be careful to determine whether the client is concerned about a bug or a change to the system. At this stage, any post-handover changes requested by the client are almost certainly outside the scope of the specification, and as such should be considered additional, billable work.
Always respond to bugs reported by the client as a priority, even if they appear to be nonbugs (for example, the client has made an error). Use a bug tracking system such as Mantis to keep track of all bugs reported, and give clients access so that they may report their own. Encourage clients to use this system in preference to immediately calling you about it.
Clients are generally sympathetic to bugs; most people these days are enlightened enough to accept that "these things happen." Being seen to respond quickly, efficiently, and systematically, even after the system has gone live, is often the difference between being on the receiving end of sympathy versus angry telephone calls.