|
|
If I achieve anything in this industry, I shall consider my time well spent if I wrest creative - production - design and scheduling control away from the accountants and marketing people. That sounds arrogant doesn’t it? OK, I see it like this. We all have a part to play in this business. An account has absolutely no idea of the technical content of a project. Since they are trained to manage finances and are basically very skilled only in the art of cutting costs why do company executives let the accountants dictate how much is going to be invested into a project or even worse dictate when it has to be completed? Likewise, the Marketing people are great at coming up with concepts and opportunities but know marginally less about the technical aspects of software development than a hand reared armadillo. Lets make sure that everyone in the chain understands their responsibilities, and more importantly has sufficient respect for the expertise in the areas they don’t understand. I would organise a company like this.
Give the marketing people the responsibility of looking for new product ideas and as part of that study, they need to identify correctly the window of opportunity. They should not be dictating the delivery dates of a product at this time. They should merely find suitable potential projects.
Then, the projects can be scoped by the technical staff to work out the resourcing available. When this is known, the executive board can decide whether to initiate a project or not. It should be clear at this point whether the company can develop the project within the available window of opportunity with the resources it has available.
At that point decide whether to begin the project or not. Do not embark on projects that you think you may not be able to cope with. Do not embark on projects for which you don’t have the resource. Do not embark on projects that you think you will not be able to commence on the planned date. This last one is a key point.
As part of the planning, the development cycle must be followed afterwards by the testing and all the usual product packaging. When it is clear that the project is nearly complete, it is time to allow the sales staff to commit their plans to action. They may already have done some preparatory work but do not commit to the advertising or server space until you know that the project is going to be completed on schedule.
If your planning goes well and everyone is prepared to co-operate, things should mesh correctly and you will reach the deadlines. The important factors are that technical specialists did the technical planning and not accountants and marketing experts who made a guess at the time it would take.
If the project goes badly and needs to be delayed, unless you have the sales people firmly in control, you will not be able to defer the deadline if the adverts, distribution arrangements and production processes are already committed. You cannot be sure that you will not encounter a technology barrier unless technical people appraise the project concept early on.
In a lot of projects, I have seen the deadlines being set before the technical appraisal, the promises are then made to the clients and the conceptual design begins. At this point the project scope grows and the programmers already being over-committed to other projects (due again to the accountants being in charge) are not free to begin on the due start date. Or the programming may be deferred because the client has not given approval. Or it may be held back pending the purchase order. So the programmers start in on the job later than planned. But the Marketing people have made promises to the client and the accountants make all their plans for cash flow around the delivery on time of the finished product. WHEN WILL THESE PEOPLE BEGIN TO UNDERSTAND THAT 10 WEEKS WORK TAKES 10 WEEKS TO GET DONE. Adding more people to a late project only makes it later still.
I will do my best to try and help these people realise that if you delay the onset of a project, you simply must take account of that in the time schedule. I don’t expect this to be an easy battle to win. To some extent, because this is the case, I’m likely to get called in as extra resource in these emergency situations which as a freelancer is good for business of course. But I do think its better to plan and organise more carefully than to fight fires continually. This also has a direct impact on product quality.
Check out the whole list of Cliff's pithy tips for Web developers.
|
|
