Deluge of Project Documentation

I have heard of projects where a huge number of project documentation is required. The number of project binders sits proudly on desks and shelves, exuding the aura of importance and completeness.


I have found that nothing can be further from the truth. Many of these documentation took a long time to create, edit and review...and never used again. What a waste of effort and time, time that could be have been put to better use.

However, I do agree that documentation is required. There has to be a balance as to what is essentially required, what is nice to have. Those that are essential to the project will always be referenced, used, corrected, modified to reflect the project's current status.

Documentation should be used as a means to record critical decision points, important design elements and motivation behind the through process.

I do not recommend going overboard with documentation. A careful selection of project documentation will serve the project well during its formative stages, through its operational phases and till it is retired from operation. Add in additional documentation only as needed to serve a critical specific purpose that can be used throughout the project's lifecycle.

Bernard
---------------------------
Save This Page
Copyright © Bernard Ong, 2006-2011.
All Rights Reserved
http://RescueSoftwareProjects.blogspot.com
http://www.bernard-ong.com
http://mrbolt.blogspot.com
http://BuddhismToday.blogspot.com

Tight process required to successfully manage projects?

 Is a tight process really necessary to manage a project successfully?

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
http://www.bernard-ong.com
http://mrbolt.blogspot.com
http://RescueSoftwareProjects.blogspot.com
http://BuddhismToday.blogspot.com

Rescue a failing software project?

 Can a failing software project really be rescued?

The answer is YES...with a few qualifications.
Can a failing software project be rescued in the traditional sense? No.

Let me explain.

The word "rescue" is vague. It carries a lot of different expectations and perceptions. To some, "rescue" means saving the project so that it can complete its original objective, on time, on budget. To others, "rescue" means completing the project. Other opinions refer "rescue" to "mercifully" terminating the project.

So you see, rescuing or saving a project is very possible, depending on definition and expectations. But all this is a play on words.

The real question is whether a failing software project can be saved such that the project completes its original objectives and make an attempt to be on time and within the stipulated budget. My honest answer and experience is that sometimes it is possible, at other times it is impossible.

Why impossible?

For example, if a building were built on an extremely weak foundation, or the building plans were drawn out with major defects, the building will be deemed as unsafe and will probably have to be torn down where rectification works will not suffice.

Likewise with software projects. In fact, besides the technical aspects, the more important aspects are expectations of timeline, cost, ego,  and pride. If a failing software project were to be rescued, it has to be looked at from the technical, timeline and cost aspect. If there is too much ego, pride and politics involved, the rescue will never succeed. Maybe it was these softer issues that caused the project failure in the first place.

My humble opinion.

Bernard
---------------------------
Save This Page
Copyright © Bernard Ong, 2006-2011.
All Rights Reserved
http://www.bernard-ong.com
http://mrbolt.blogspot.com
http://RescueSoftwareProjects.blogspot.com
http://BuddhismToday.blogspot.com