Book Review: Architecture-Centric Software Project Management - A Practical Guide

Architecture-Centric Software Project Management by Daniel J. Paulish.

Content In General:
The central theme of this book is project mangement revolving and based on the architecture of the software product i.e. Architecture-centered software project management (ACSPP). The software architecture has strong influences on the size and effort required for the project, and the architecture should be developed as the project plan is been developed, in order for the project management to be effective.


Contents In Detailed:

1. Introduction to project management, and software architecture. Also briefly introduces some of the core project management processes like planning, organising, implementing, measuring.
2. ACSPP - a project management methodology using the architecture of the software to be built as the basic for effort and schedule estimation, subsequently for project controlling. Briefly mentioned top-down estimating techniques (like COCOMO, Function-point analysis); also contrasted with bottom-up estimation techniques and the pros and cons of using each technique. Paulish recommends usage of both sets of techniques in projects to achieve stakeholder's buy-in at management and development team levels.
   
3. Project organisation, again using the software architectures as basics.
   
4. Issues that should be considered in global development or distributed development environment.
5. Generics issues like role of project manager, trade-offs and project decisions, incremental development, reporting and metrics/measurement. Each is mentioned a chapter of its own, in general without going into much specifics or technicalities. Some 'best practises' or 'rule-of-thumb' were recommended.
6. Two case studies were included at the end of the book.
   

What's Good:

• Good readability - Ideas were conveyed in simple and straight-forward terms.
• I especially like Chapter 2, which detailed how PM processes ties in with the developement of software architecture. Paulish advocates the need to have a distinction between the project manager and solution architect, and the need for these 2 roles to work closely together to derive a project plan that is both realistic and feasible.
• Good for beginners to project management to get a broad overview and some of the best practices, without having to be tied into the specifics.
  

What's Bad:

• Most of the content pertaining to project management are largely generic and are repeated from similiar literatures e.g. need for high visibility in schedules progress reporting,and features-time-cost trade-offs. For experienced PMs, these are most probably already known information.
  
• Specifics for techniques were found to be lacking. Example, estimation methods and risk management techniques were only very briefly mentioned. External resources will definitely be required to understand applications of these techniques in real-life situations.

Key Learning Point:

• Project planning and estimations cannot be done in isolation without consideration for the architecture of the software product. As the architecture has a strong influence on the size, and complexity of the final product, it also means that project factors like effort and time are very dependent on the architecture.
  
• The architecture should be developed in parallel with the project plan during planning, and both project manager and the architect should work closely together at this phase.