| Articles Home |
Planning a project schedule for an ERP implementation or a large database development project has been shown to be a difficult process. With the many factors like budget, personnel, market window, technological risk, etc., many scheduling attempts are wildly inaccurate. Here are a couple things I do for scheduling that have proven to be an accurate strategy for every project I have done without exception. Those things are buy software early, buy hardware late.
If the project needs significant hardware to implement, push the actual purchase and delivery of hardware as far out as possible. The advantages to this strategy are many. One, is that hardware bought later is better, sometimes by magnitudes of ten. That big storage array bought too early will look like yesteryears eight inch floppy compared to todays CD-RW disk. Another reason is that hardware bought later is cheaper. A year long project is a long time in the hardware market, costs drop dramatically. And that million dollar set of boxes and cables is worth nothing on the secondary market when you take delivery. If the project is cancelled ... Well, it is a lot cheaper not to buy it. More reasons: Hardware needs resources to support it. Machine rooms, network hookups and cabling, UPS, backup strategies and equipment, personnel. If these are not in place the organization cannot implement and hardware not installed is dead money, see above.
Even more reasons: Strange as it may seem, I see over and again people do database development on production hardware and then "go live". The production environment is then a mess of developers accessing resources, scratch code, security problems, trashed file systems and instability. It is better to develop in a test environment or development environment and late in the schedule install a fresh production environment on the new hardware. It promotes good configuration management practices.
Another reason is that "Big Five" contracts will get rake-off on hardware and will have you buy too early. They have then locked in profit for the contract off you. Cancel the contract or go bankrupt they don't care, they got theirs. Welcome to the real world.
Now, when do you have to buy the software needed for a project?
In a large database development project buy software right away as soon as there are people to use it. Get the real thing, not a "personal" version or limited license version. People must get familiar with the software right away, including the system administrators who install it and manage it. Software prices do not change greatly or devalue like hardware so waiting has little cash advantage. If it is opensource or freeware there is no excuse not to get going as soon as the software is specified.
I just said do not buy the hardware until late in the project, so what is the database and other software going to run on? Run it on a small development box or an old piece of that hardware that Joe Blow blew his budget on before they cancelled his project. During the configuration and development phase a database project rarely needs those 6 clustered 32 CPU SMP boxes and that 10 TB array. The only thing is to run it on the actual OS that it will use, do not develop on Microsoft OS for software that will run AIX.
For an ERP project or any other development project before the software design is even finished there is plenty to do: Get familiar with installs, backups, disaster recovery, configuration of software, the development configuration management, testing process, release procedures, archiving, customization, printing. This is the preparation of a successful development environment. All this takes time and people to learn. When the software design has been finalized and coding begins it is not a good time to start learning how to do backups of the database and having glitches in basic administration of the OS and software that affect the developers progress. Figure out how to restore and recover from a disaster before it is a busy development environment, you will live longer by avoiding heart attacks and strokes.
Many times I see projects falter with development on PC fake versions of the software that will just not cut it, cheeze bag packages like Personal Oracle or Personal PeopleSoft. The developers spend valuable project time messing with the configuration of the "Personal" software instead of developing, project development struggles along with most of what gets done not being really "done" as testing whatever is actually created is difficult, and a project release is is not possible without the real versions of OS and software. If the real problems of configuration are not handled early in the project schedule the risk is very high that the project will miss milestone dates and affect the schedule. Get the real thing. Develop it on the production OS, you can find smaller, cheaper hardware than the 128 CPU cluster that is specified in the final production architecture. The operating system (OS) will have plenty of quirks, do not waste time on a substitute OS. Of course, if you are in the business of developing rinky dink apps I am not talking to your development process.
For a database development project get the development, test and configuration management environments set up as quickly as possible with the tools and software really used by the project targeted to the hardware and OS architecture to be used. The big hardware money does not need to be spent until late in the project. So, do not be an idiot and develop on Windoze thinking you will save money. For a deliverable on AIX, for example, get a small AIX box and make sure the software installs and is tested on the OS architecture. Do not put this off until a week before delivery. The project will fail. There is no C: drive on a Unix machine, pal. And running everything as root is a sign that you do not understand security. The project time saved by not configuring the fake PC environment and then having to port to the real target platform will more than pay for any "savings" in hardware and software.
Software Engineering Basics This article
Software Project Planning Tips
Capability Maturity Models and Software Engineering
Choosing Software Contractors
Manage Your Software Consultants
Outsource Your Software Problems