The Design and Implementation of laffer1

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. 

I started wriing this entry with a real world experience I had today.  Instead, I think I'm just take some constructive points from the situation.

1. When making a big picture roadmap with many IT projects, understand what each part is trying to accomplish.  You don't need the how for the first draft, but you do need the why.
2. Don't create three level deep diagrams of one component in the system that interoperates with other peices not even discussed yet. 
3. It's ok to talk about when you need a project complete, but don't start makin details timelines or final deadlines until the requirements are known.  You can't plan how long something will take when you don't even know what it is you're planning.  If you have a hard deadline, start with absolute necessities first.  Good software can always be enhanced.
4. Don't assume everyone is against your idea.
5. When you're asking someone to spend a great deal of money on a project, take the time to write down why you need it..  It really is the least you can do.
6. User stories are one way to obtain an initial list of requirements, but they do not replace a techical oriented view before one starts work.
7. When writing user stories, you must capture ALL of them or it is useless.  One user case left out could dramatically change the requirements for a project.  Programmers do write themselves into corners.
8. Reading one book will not make you a good project manager.  Reading this list won't either.
9. Don't trust any one website for information on software.  They can be wrong.  Some IT websites suggest products because vendors paid them or gave them an insentive. Others just have a bias.  For example, I might suggest  BSD because I prefer it to Linux.  That doesn't mean Linux isn't useful in many environments.
10. Programmers need to sleep sometimes.