Software Project Management: A Real-World Guide to Success Review

Average Reviews:

(More customer reviews)As I repeatedly tell the students in my software engineering classes, less than twenty percent of the work building a software project involves writing the code. The vast majority of the work is in capturing the requirements, constructing the design, critiquing the requirements and design; getting and incorporating customer feedback; testing the code and verifying that the requirements have been met. In fact, when you add in reasonable time for training and interacting with new tools, the percentage of the effort that is writing code is probably closer to ten percent. If you also add in the time spent organizing all of this effort, then the effort that is actually writing the code is in the area of ten percent and may even be lower.
At least one week of the year is spent in midweek holidays, leaving at most fifty-one weeks of work. I have never seen a compiler upgrade that didn't take at least a week to iron out all the details. Since most tool update cycles are annual and the wise organization is always evaluating new tools, close to five percent of the effort is probably spent in evaluating and integrating new tools. Henry mentions several different problems in this area, he understands that the seamless change of tools is a fantasy, found only in advertising flyers.
Whether you see it in the schedule or not, training also takes up a minimum of five percent of the team effort. Developers either learn as they build or learn before they build, but either way the time is spent.
Choosing the appropriate training is a nontrivial task. With few exceptions, the training needed by any group is different from all others. As Henry points out, when considering training, search out specific details about what is being offered. The training may be excellent, but if it is an overview when you need to know specific details, then it may be of little value to your organization.
The emphasis in this book is on the organizational features that make a project successful, the critical part that is keeping everything within acceptable bounds, from the original idea to the shipping of the product. High quality managers do not have to know a C program from a sea serpent, but they do have to be able to spot potential failure from the other side of the ocean. Most software developers will not admit to significant problems until forced, and the good manager will be able to read body language, tonal inflections and general appearance to determine if things are going well. This is impossible if you do not know the people well and have some familiarity with how they conduct themselves. There is always some degree of tension between boss and worker, but if the employee knows that honesty is rewarded, then the level is lowered.
However, this is just on the reactive side. The good managers are proactive, examining the situation on a regular basis, looking at what should have been done and asking the tough questions to determine if things are on the right course. They also must change the course if necessary, and this can only be done right if you have a set of measurements that accurately describe the current situation. Chapter four is a detailed description of how to choose measurements that apply to your project(s).
Henry explores in detail some of the specific requirements of a software project that are often ignored in other books. In chapter six, the emphasis is on the background requirements, the hardware, software and support needed for the project. The points for hardware are:
* Specify what the hardware needs to do.
* Specify what the hardware needs to be functional.
*Specify who needs what hardware.
* Specify when the team needs the hardware.
Simple points, but often overlooked both by authors of software project management books and in practice.
The author is clearly someone who has learned from experience, much of which is the best kind, negative. A great deal of the activity in a software development project is now organizational. How to examine and organize the requirements, how to make and carry out the assignments of people to tasks and how to track the progress using processes that actually measure what has been done. The author describes all of this in detail, with advice that I have incorporated into my software engineering classes.

Click Here to see more reviews about: Software Project Management: A Real-World Guide to Success

Product Description:
Software project management principles are presented, in a friendly tone, in the same order they appear in actual project progression. This book focuses on applications rather than topics.The culture of a software project team, the leadership technique that will lead to success, and the importance of the process itself are all closely looked at.Multiple sources from both academic and professional situations are integrated into the text to give it a broader feel. Professional Software Engineers; Software Project Management and Project Management courses. Previously announced in the 10/02 catalog.

Want to read more honest consumer review about Software Project Management: A Real-World Guide to Success now ?