| 23 March 2007:Not losing your shirt |
In this issueFeatured article Not losing your shirtIn the previous newsletters we covered the first two stages in getting a project started:
This month I plan to cover the project. You can lose your shirt on a bad project and IT people have a way of running projects that limits the risk. I want to explain why they go about it the way they do. The planThe planning process is very simple:
The process is no different to planning a meal, 10mins preparation, 5 mins frying etc then just add up the time and figure out how long it will take. Tracking progressAs each work package is complete you can compare planned and actual time and revise the plan. So if preparation took 15 mins you are 5 mins behind schedule. It is a handle-turning process to continually predict progress against plan and picking up situations where you are going over budget or over time early on when you can do something about it. As the job progresses you (or the client) will find things that need changing. Any change has the potential to cause delay and extra costs, so it is important that changes are recorded and costed. Any changes need to be plugged into the project plan and the end-date and budget re-worked. The work can also be delayed because the client is slow in providing information or making decisions. Sometimes you can work round these delays, but often not. If a delay in a work package effects the overall time then that work package is said to be on the 'critical path'. Again the plan needs reworking and the consequences explained to the client. If people are left idle then the cost of the project can be effected. A large project can have hundreds or thousands of deliverables and work packages. Organising this is a big clerical task and computer systems such as Microsoft Project have been developed to manage all this data. For the projects you are likely to be dealing with you don't need this, a spreadsheet will do the job quite nicely. If you do splash out on Microsoft Project, don't fall into the trap of getting too complicated. I have seen complicated project plans for quite simple projects that are works of fiction which will not survive the first week of the actual work. The techniques to manage an IT project are no different in principle from those used to manage a big building project or an engineering project or for that matter cooking lunch. There are proprietary methodologies and tools to back up the project manager, but they are all based on the process outlined above. PRINCE2 is the British standard methodology and any large government project will use PRINCE2. What can go wrong?Here is an example. A client issues a brief asking for an ecommerce site. In the course of meetings they mention that they want to sell world-wide and your salesman nods his head and says no problem. Of course as every schoolboy knows anyone from anywhere in the world can go to your site, enter their credit card information and in due course the equivalent in their own currency will be billed to their credit card. No problem. The salesman sees that this is a bit of a pre-occupation and makes sure that selling world-wide is mentioned in the proposal. You build the site and it looks good. Progress is tracked and you are on time and budget. Then when you have the site over for testing the client looks at you with guileless innocence and asks: “What about world-wide sales. How can someone in the US buy something if the prices are all in Sterling?” Someone quickly finds a currency converter that you can put on your web site for free, so with a small amount of work you can put a currency converter on every page. Problem solved. The site goes live, and after a couple of weeks you get an angry call from the client. The currency converter says that the price of a product is $25.30 and an American customer actually found $25.70 on their credit card. The American customer thinks he is being done and will not be using the site again. This is a crisis you have to something - and now! You try and explain that the converter only gives indicative rates. The bank not only might use a slightly different rate but they add a profit margin on top. While you are talking you can see that the client has no interest in what you are saying. They have a problem and instead of trying to fix it you are babbling on about exchange rates. You are at this point basically dead. There is no quick fix. By adding the currency converter you accepted that presenting prices in foreign currencies was your responsibility. If you had faced the problem then you would be OK now but your quick fix has left you in the mire. What has gone wrong? Very simply you failed to do what I have been trying to emphasise from the brief to the proposal which is to make sure that the requirements are totally nailed down in some sort of specification document. Whatever document is to be the specification; vague statements about 'selling worldwide' are a complete no-no. If you say something like that you have to explain what you mean. The second essential is that your terms and conditions state that the specification is a complete statement of requirements and other items are not included even if they were previously discussed and agreed. Both of these are key steps. A good specification and a systematic approach to project management and your shirt is safe. |
 |
|
 |
