Last year, my fellow columnist, Ken Hanley the IT Guerrilla, wrote that if you try to plan in detail more than six months ahead, you’ll have problems. I completely agree with him.
Our clients, internal or external, want to know exactly how much a project is going to cost and they want to use the project plan for building a return on investment picture and a project budget. They want a detailed plan; the more detail the better. I’m just as guilty as the next guy. I’ve written some challenging Requests for Proposal (RFP) in my day and I’ve answered even more.
Why do companies (and you, dear friends) write project specifications that demand absurd levels of detail and extremely complex project plans when the person responding has to do so without knowing the details of the organization, the project or the goals? Possible budget ranges, the number of internal staff contributing to the project and the desired vision of the company at the end of the project are actually dark secrets. In the usual proposal process, the people responding end up scrambling to second guess what the level of detail should be, how much it should cost and how much bang is desired for a given buck. Governments and some large companies are notorious for this, even when dealing with internal IT departments.
Let’s face it, the more complex the software the more expensive the implementation. The more changes required to packages to respond to so-called mandatory requirements, the longer it takes and the more it costs. These are pretty basic facts of IT life.
I have a rule of thumb that says if you can’t achieve at least one element of value in six months or less, re-examine the project and start talking. That applies to IT departments in companies, consultants and individuals. In my experience, be wary of the RFP or the proposal that goes into great detail beyond six months. A high-level plan of the whole project should be there, but not to the point where you could actually follow it closely. With the speed of change in the industry and the economy, the whole picture will be different in six months.
A more intelligent approach would be to ask what defines a low bid. Better yet, why not ask for a low bid, an average bid and a high bid with a description of what is provided (or expected) at each level. If you know the project is going to take a long time to complete, it might be smarter to find out what we’re going to do to establish an on-going relationship. It’s difficult to create a team internally when other company demands mean switching people in and out of the project. The same thing applies to consulting firms when half the team is from somewhere else and very few will be there for the project duration. In this new electronic age we have the e-FOOT – an expert From Out Of Town.
We’ve all seen projects where everyone is part-time and where continuity or the will to succeed are lost. Two things usually happen. Firstly, what is delivered is less than optimal for the company, and secondly, when it is finally in place company staff will have difficulty operating or maintaining the new system without assistance. That’s usually the point where the IT organization, internal or consultants, receives the blame.
It would be nice to read a project plan where someone asks serious questions about value, quality, ethics and partnership, and then says “Show me.” Establish the relationship and the rest is a logistics exercise.
Horner is a partner in Sierra Systems Consultants, Corporate Enterprise Systems practice. He can be reached at alhorner@sierrasys.com.