Project Delivery System, 4th Ed

This book was highly recommended by a project manager I respected as someone very highly experienced.  The book presents the project delivery system used by the engineering firm CH2MHILL. It covers the topic at a very high level, and is very straightforward and practical.  It is by no means complete.  I doubt if CH2MHILL uses this and only this as their project delivery system.  For example, it does not tackle progress monitoring.

Project Delivery System: Fourth Edition: CH2M HILL Project Mangers: 9780965261616: Books ISBN: 0965261611 ISBN-13: 9780965261616

I found the chapters on planning the project, and the one on building customer relationships clear and enlightening.  They are the best parts of the book.

If you work in a project where there is no project management process, this book provides a framework (but no more than that).  It does not explain what they mean by ‘Project Delivery’ as opposed to ‘Project Management’. 

Listed below are some of the books referenced by the above work.  This list is not necessarily complete (sometimes, I list only those that interest me).  The Amazon links are to the latest editions of the book, not necessarily the edition cited in the above work. 

Items marked with a , are works I can recommend.

Title	Author	Remarks
Force For Change: How Leadership Differs from Management	John P. Kotter	Amazon
Principle-Centered Leadership	Stephen Covey	Amazon
The Leader-Manager: Guidelines for Action	William Hitt	Amazon
The Empowered Manager	Peter Block	Amazon
Crisis & Renewal: Meeting the Challenge of Organizational Change	David K Hurst	Amazon
Leadership, New and Revised: The Inner Side of Greatness, A Philosophy for Leaders	Peter Koestenbaum	Amazon
The Fifth Discipline: The Art & Practice of The Learning Organization	Peter Senge	Amazon
Engineering Management: People and Projects	Murray Shainis, Anton Dekom, and Charles McVinney	Amazon
Managing as a Performing Art: New Ideas for a World of Chaotic Change	Peter B. Vaill	Amazon)
Productive Workplaces: Dignity, Meaning, and Community in the 21st Century	Marvin R. Weisbord	Amazon
Stewardship: Choosing Service Over Self Interest	Peter Block	Amazon
Customer Bonding: Pathway to Lasting Customer Loyalty	Richard Cross and Janet Smith	Amazon
Service Breakthroughs	James L. Heskett	Amazon
The One to One Future - Building Relationships One Customer at a Time	Don Peppers and Martha Rogers	Amazon
Value Pricing for the Design Firm	Frank A. Stasiowski	Amazon
Managing Transitions: Making the Most of Change	William Bridges and Susan Bridges	Amazon
Getting to Yes: Negotiating Agreement Without Giving In	Roger Fisher, William L. Ury and Bruce Patton	Amazon

UML Review–Views

A brief review of UML.

UML is a modelling system.  Every model is a simplification of the real thing and is intended to highlight the focus of that model and to recede what is not important for that particular model.   Reality cannot be modelled fully.  We will always have to select the perspective, or ‘view’, that we want to focus on.

UML is designed around a set of views. Its notations allow you to create diagrams that model a particular view.

Static View. The static view models the structure of the application domain. You use the Class diagram to represent the static view.

Use Case View.  Shows the functions of the system in its interaction with entities outside of it.  These entities are the ‘actors’.  The functionality is grouped together into use cases, where a use case is a specific transaction (or usage) of the system.  The Use Case diagram is used to present the Use Case View.

Interaction View. UML being object-oriented oriented (sic), entities communicate with each other through messages.  The Interaction View shows the message-passing interaction between the entities (strictly speaking, ‘between the roles’). UML has two diagrams that capture these interactions, the Sequence diagram, and the Collaboration diagram.  The Sequence diagram shows the messages and their sent between the different roles as each role requests and responds to the messaged.  The collaboration diagram focuses on the links between objects during an interaction.  So while the Sequence Diagram highlights the messages and their sequences during a specific transaction, the Collaboration Diagram highlights which objects are involved in the same transaction.  There is clearly some overlap between the two diagrams, and in practice, the Collaboration Diagram tends to be given up in favour of the Sequence Diagram.

State Machine View. Unlike the previous views, the State Machine view focuses on only one object or class.  This view models all the possible states of an object, what states it can transition to from each of those states, and what would cause it to transition to each of those states. The statechart diagram is used to draw this view.

Activity View.  This view maps the activities performed by whatever entity we want to model.  We do not have to pick an entity, in fact, and just proceed to model activities related to a particular outcome.  This view is similar to a project network diagram in that it simply maps dependencies and sequences of activities to produce a result.  You use the activity diagram to create this view.

Physical View. The physical views leave the world of concepts to model the physical realities.  There are two physical views in UML.  The implementation view shows the various software components and the links between them.  This is captured using a Component Diagram.  The other view is the deployment view, which shows the software components in the physical computers and servers they will be deployed in.

THE TRIPLE CONSTRAINTS ANOMALY

You cannot possibly be a project manager and not have heard of the term 'Triple Constraints', and the surest sign that you are a novice project manager is your belief that the Triple Constraints is made up a 3 things.

That is one of the odd things about this term.  Originally, it was indeed about three constraints: Cost, Time, and Scope – project and programme managers have to deliver the goods (Scope), within the budget (Cost), within the schedule (Time).

Later, thinkers thought to add 'Quality' because well, sure, you can deliver the goods, but are the goods you deliver up-to-spec?. So the Triple Constraints began to consist of four items.  There are some heretics (or perhaps they are prophets of wisdom) who insist that Quality is just part of Scope, and ought not be considered separately from the other.  The argument is, if you delivered 600 green umbrellas rather than the required 600 red umbrellas, it is not a 'Quality' problem but a Scope problem – you simply didn't deliver what was asked for.

Project managers with more than a week experience, began to realise that despite their personal charm, the world doesn't revolve around them or their naive assumptions. 

Things go wrong.

"We need to add another constraint - Risk", came the chorus. And so the Triple Constraints became five (and have to be redrawn as a pentagon – we are not geometrical ignorami, after all)

Courageous project and programme managers soon began to point out their specialty: delivering goods within the constraints of time, cost, scope, quality, and risks. There is no need to be mean-spirited by reminding them that postmen and newspaper delivery kids and mothers and housewives, have been doing the same since the invention of anything.

But no matter how well we think we manage the five constraints, projects still tend to head south, and so we need another constraint to lay the blame on.

Resources.

"Surely Resources are a constraint!" came the battle-cry of the project and programme manager. "Even if I have a budget of $50 million if I cannot find Fortran programmers, my Fortran project cannot succeed." And of course, when they burn up my $50 million without delivering anything, they can point to the incompetent resources they had to work with. 

But let's take a step back (after first checking we are not on the edge of a cliff; risk management in action).

We can take the view that the constraints are about what a project manager has to deliver against. Or we can take the view that the constraints are 'natural' limitations that enterprises have to balance when deciding which projects to undertake.

We want to finish the project as soon as possible so we can reap the benefits and start other projects as well. But to finish faster means applying more resources. This is a natural constraint in our world.

We want to do it right the first time, but it will mean more time and more cost, so we may need to cut a little bit of scope here and there. Another natural constraint.

We want to deliver the project as cheaply as possible, but if we put a limited number of resources will take the project that much longer to finish. Another natural constraint.

I think the Triple Constraints are about having the enterprise (not the project manager) balance between the 3 (not six) constraints.  The project manager, for his part have to deliver the Triple Constraints while working through the constraints of Risks and Resources. (Quality is part of Scope).