Requiements capture

Gathering requirements is both an art and a science. There are numerous project templates on the web that can be used to capture or gather project requirements.

It is a science because these templates guide an analyst to gather the user requirements for a project. It is an art because the template only has headings or guidelines. It is a generic template and the analyst has to use common sense and industry knowledge to probe and distill user requirements into a specific, measurable and deliverable requirement.

Most requirements focus on the functional aspect of a project. These are termed "user requirements". These are the functions or use cases the user must have or would like to have delivered through the project.

The architectural requirements are normally done as part of design, or worse still, an after-thought. I define architectural requirements as other requirements not pertaining to the functional aspect of the project. For example, security requirements, performance requirements, scalability and extensibility requirements, availability requirements. From this list alone, you can deduce that the term "user" goes far beyond the business user or the user that specifies the functional use cases. The project team's interaction must now encompass the customer's security team, systems and infrastructure team, application maintenance team.

If requirements capture is viewed in this manner, the project team will begin to identify the various "users" needed for project success and begin building close working relationships with the extended eco-system. The relationships cannot be a one-off relationship. It is an on-going relationship as the project progresses.

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

Reviews are critical in project management!

Core technical skills, software design, writing code are all considered important and critical activities of a project. The perceived "softer" activities such as regular project reviews are considered optional.

This situation is very common in projects. Software design and writing code produces visible results such as the software module or use case that can be viewed and tested. You can't see or view the result of project review. If project reviews are done correctly and properly, and the project progresses without major issues, no one will acknowledge or miss the importance of project reviews. The importance of project reviews are often overlooked.

In my experience, project reviews, if done correctly and properly, keeps the team focused, productive and more importantly, effective. In my opinion, it is a critical activity.

However, how many would agree to this? If the project is on track and progressing well, no one will acknowledge this point. If the project is failing, some may acknowledge this point, others will blame the software design, code quality, coding standards, scope creep. While there is some truth in this, project reviews help prevent major catastrophes and at least, identify and highlight such catastrophe may be on the horizon and the team needs to take corrective action.

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

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