11:08 PM - The other side of the coin
I just read a blog for CIOs about planning IT projects. In this blog, it suggested that CIOs or a "core" team plan deadlines for large projects. As a software engineer who essentially is the project manager in my office, I found this article disturbing. The reasoning behind the aritcle makes sense from a CIO's perspective given several other requirements.
The company must have one goal in mind with the project. Personel cannot be "stolen" for other projects. There cannot be fire drills every day. Most importantly, the CIO needs to understand how long it will take to create a project. A reasonable time frame must be defined. My experiences have shown that management has no idea how long projects take. That poor, young project manager might not have a good idea how to do estimates yet, but (s)he does know how large a project is.
In some companies, this approach would work well. It will not work in all companies. The approach is getting used more frequently in my company. The net result is dropping everything and putting everyone on a task. It does get that one task done as quickly as possible, but the quality of the project suffers. Further, it puts every other project behind schedule. Sometimes project managers are right. Things happen during development. Odd bugs pop up. New requirements are brought in during development.
While I'm on the subject, it's also important to have clear goals for a project at the beginning. This approach reminds me of the waterfall method. WIthout a very clear, well thought out specification, large software projects will always fail or at least be delivered well after the due date regardless of who sets the timeline. You get some leway with agile methods, but you still need to know what you're trying to make.
I agree with one point. It's important to have clear goals defined for your IT staff. Tell them what you need this year. Give them time to implement long term solutions. It will save you time and money.
I better stop here.