Thursday, May 17, 2007

Status Reporting About Software Projects

Perhaps, the most common word used in the IS profession is the word "project".

Projects give rise to more words in the vocabulary of the IS professional. He/ she understands that the daily work involves beloging to "project team", reporting to a "project leader/ manager", adhering to schedules and deadlines during the project life cycle.
Projects can be big or small, complex or simple. On the whole, the scope of project, number of people working and managing the project, time and money spent determine the "hugeness" of the project.

An area that draws my attention at this point is status reporting. Teams report on the status of the project among themselves, their co-ordinators and several people connected with the project. The word "reporting" makes it sound formal and professional. It is to be understood that teams "communicate" to discuss the problems to be resolved under the umbrella of project status reports.

I often wonder and question about the "honesty" expected while communicating on several issues about software projects. I would think that the degree of honesty of people involved is a true measure of the success or failure of a software project.

Why is it difficult to be honest about the knowledge on the "problem" taken up by an engineer regarding the issues to be resolved? Why does mistrust among the team members themselves seems predominant during status reporting?
Why is it difficult for a project manager to be able to honestly predict the time and resource required for the project that one is accountable?

Perhaps the lack of comprehensive knowledge on the issue at hand is the reason behind the exhibited mistrust and dishonesty.

This is a serious issue that every professional faces many times in his / her career - yet does not admit once he/ she is out of the scenario.

Here, I must mention an article "Why Big Software Projects Fail: The 12 key questions" by Watts S. Humphrey of the Software Engineering Institute (The Journal of the QAI, October 2005)". The article raises 12 questions related to big and complex software projects, the type of dilemmas people working on such projects face. The ways and methods of project management of software projects is questioned with substantial evidence. The questions expose the nature of problems of sotware project management in particular.


Paradigm shift in the management of software development projects is a hope to ensure high rate of success of complex software development - that is a recognized issue. People must be empowered to be straight forward and honest with their software professional lives. For this trust and belief about themselves and others must be culitivated and fostered in the organization. Efforts such as the Team Software Process (developed by the Software Engineering Institute, Carnegie Mellon) is perhaps a step towards achieving more trust and honesty among team members of a project according to the article.

Another reference along the lines of the issues as the above one is
"Defining and contributing to the Software Development Success" in the Communications of the ACM, August 2006 / Vol. 49. No.8 issue.
The main theme is "Project managers should try to support a challenging, autonomous, and creative work environment…".


Points to Ponder:

0. How do organizations ensure that the project managers and people responsible towards the projects progress are qualified for the work on hand?

1. What tools do Project Managers use to determine the progress and performance on projects?

2. What are the general measures used for success of projects? Are they enough?

3. How can people contribute better to project success?

4. How are open source projects managed?

5. What are the pros and cons of project management by hierarchical and team methods?

6. How are revisions for improvement handled by project teams?