How to Rescue Failing Software Projects: Practical Proven Methods That Work
My book is finally available as an eBook, on Amazon Kindle and on Amazon. I wrote this book to share my experience in how to rescue failing software projects. When I was going through such a situation, I had no one to turn to. My hope is that the information in this book will be useful to those in similar situations. Although the information in the book pertains to software projects, I have come to realize that the techniques can be used in many other situations. I have personally used these techniques in business and technical projects.
Wednesday, March 23, 2011
Tight process required to successfully manage projects?
Well, yes and no. A-ha! Another one of those wishy-washy answers! Well, yes and no.
A project manager must understand the need for a process and the benefits it brings, together with the disadvantages it inherently has.
Why is a tight process beneficial?
It allows the project to progress like clockwork. It provides predictability to every activity, every behaviour from team members, every deliverable. Sounds too good to be true, doesn't it? In my humble opinion, it IS too good to be true. A project is conceptually a set of steps organized into a set of activities that are to be accomplished by a certain time with a set of finite resources (people, technology, budget to name a few). A project is a living, breathing part of life. Life is as predictable as the next second in time. If a project were to be run with such an extremely tight process, it will kill team morale and team innovation. Yes, innovation in a project may seem far fetched. Innovation and creativeness are required in projects to enhance effectiveness of systems, to find solutions to very tough problems.
On the other hand, without a tight process, a project will be run like a country without any government. No direction, no leadership, no guidance and doomed to failure.
So how is a balance struck?
In my humble opinion, there should be a set of strict project processes that are made know to all stake holders. Exceptions are allowed only with approval from the project manager. For example, timely reporting, timeline and duration of project phases and activities, escalation process to name a few. There may be 5 to 7 broad strict processes. No one really remembers more than 7 to 10 things anyway. keep is simple. keep it top of mind always.
There should be a broad set of guidelines that create the boundary of the project. For example, identification-fix cycle duration, how much scope creep is allowable, do not design to perfection but design to usability with resuability that meets performance and security requirements.
These are my thoughts on how tight a process is really needed. A difficult question to answer indeed. This is where the project manager's skill and EQ becomes critical, how he/she manages the team's morale and effectiveness without killing innovation and motivation, while charging ahead to complete the project on time and within budget.
Save This Page
Copyright © Bernard Ong, 2006-2011.
All Rights Reserved