This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell. This is going to be a three-part post, where I talk about the stage delivery methodology.
Like in every other things in life, what had a start, needs to come to an end. The project you and the team had been developing has ended, for good or bad. Many obstacles where in the way. Some of them could be easily remove, while others where a pain the knee. There were moments of stress and moment of relief. The good thing is that the project is done and now is time to take a break, before you can start you next project. The end of the a project brings a time of reflection to the whole team. The project managers, should be gathering data of the experience of the project. They should be asking for feedback from the team members. As a piece of advice, McConnell says to ask the feedback within the 15- to 30 of releasing the software. He said this because it is when the events are «fresher» in the head of the team.
As part of gathering information, make a meeting with the whole team to evaluate how well or bad the project went. This meeting is important so can everyone can give their opinion on matters that they thing are important. The good and bad needs to be spoken during this meeting. To make sure that the meeting doesn’t evolve into a debate, make sure to have a moderator to control the meeting. Some people aren’t very outspoken, so you can also make an anonymous questionnaire, where you ask for the opinion of the project. You can make questions that can have an scale, or open question, like you wish. And lastly, make sure you have a project document history where you recorded all the project from start to finish, including the team’s opinion.
At the end McConnell, narrates an experience from the Software Engineering Laboratory at NASA, and he said how this laboratory has been making, excellent quality software for years. And he list 9 of the do’s and 8 of the don’ts of how to make successful software, according to the SEL.
DO’s
- Create and follow a software development plan.
- Empower project personnel.
- Minimize the bureaucracy.
- Define the requirements baseline, and manage changes to it.
- Take periodic snapshots of project health and progress, and replan when necessary.
-
Reestimate system size, effort, and schedules periodically.
- Define and manage phase transitions.
- Foster a team spirit.
-
Start the project with a small senior staff
DON’Ts
-
Don’t let team members work in an unsystematic way.
-
Don’t set unreasonable goals.
-
Don’t implement changes without assessing their impact and obtaining approval of the change board.
-
Don’t gold-plate.
-
Don’t overstaff, especially early in the project.
-
Don’t assume that a schedule slip in the middle of a phase will be made up later.
-
Don’t relax standards in order to cut costs or shorten a schedule.
-
Don’t assume that a large amount of documentation ensures success.
McConnell’s Software Project Survival Guide, is an excellent book to those out there that are looking to be project managers. In my opinion, I had always been interest in a PM position, and with this book I can get a clearer idea of how to make achieve it. McConnell gives some very good tips on this book. I know that if I ever become a PM, experience will be one of my helpers to become one and also this book.
Stay Safe
A.C.
References
McConnell, S. (1998). Software Project Survival Guide. Redmond: Microsoft Press.