Monday, June 23, 2014

The Sensible 12: No. 5

5. A team that takes ownership in the project will deliver successfully. When a team takes ownership in the project with the enthusiasm to deliver increased value to the customer, that project will be successful. It takes soft skills and leadership by the project manager to foster a unified team, but when successful, great things happen. A team is most effective when they understand the project vision and can gain a passion for the solution and take ownership in delivering that solution.
All fluff. A team doesn't 'take ownership' unless they are investors; pretend 'ownership' is a bit of pop-management rhetoric.
The people who are engaged in delivery have to be committed to their promise to do their job.
The Project Manager has to provide resources, direction, and the organisational setting to facilitate this. We all need to behave honourably, politely and with respect. End of story, or its the end of the story.

Tuesday, June 17, 2014

Project dimensions

In Karl Wiegers' book "Practical Project Initiation" he includes an approach to developing a view of a project's constraints.

The starting point is to map the 'five project dimensions' on a kiviat diagram (radar chart) showing their degree of flexibility.

Wiegers sees that the 'iron triangle's' three project dimensions are inadequate, and if stated as 'time', 'cost' and 'quality' he's dead right. But he re-engineers these three into five (see the illustration from his book, below): features, quality, cost, schedule, staff. There was a question as to whether 'risk' was a project dimension. Of course, it isn't; it is a characterisation or qualification of any of the legitimate dimensions and doesn't have an independent existence or basis apart from the subject that is at risk.

But is five better than three? Does it help?

My first reaction is that 'quality' is a fake dimension, and 'features' perhaps as well; (although in software development, maybe its meaningful). These two attempt to split out the one parameter that has basic meaning for the project's mission: '[technical] performance'. If I need performance at 'n' for a project, then the only 'quality' I'm interested in is in 'n' being achieved. If there's an acceptable range, then it is the performance range, not a separate thing called quality range. So performance accepted is not just 'n', but anywhere between 'n-m' and 'n+p'.

'Quality' as an add-on extra to production is unhelpful and only serves to create an add-on industry of 'quality' advisors.

The two dimensions of 'schedule' and 'staff' are also related, and I question the split. However, I can see the sense operationally, with the use of the five dimensions is to establish the constraint envelope. If schedule (I think the term 'delivery' is better, it carries a reminder that the project is there to produce things, and not just to formulate an abstract schedule) is highly constrained, then staff flexibility might be nice to know, but possibly irrelevant; on the other hand if staff is a constraint, and delivery is flexible, then so what?

BTW, I'm glad Wiegers uses 'staff', not 'resources'. Staff are people, iron ore is a resource.

So, for me, the constraints to a project, or to a work package in a large project, come from the requirements for delivery, and this is probably related to interfaces with other work packages, the performance requirements and mission the project is to be used for, and the funds available to be invested for an expectation of return (I prefer to talk business, rather than accounting).

Monday, June 9, 2014

The Sensible 12: No. 4

4. The project must deliver a quality product or service.
There is no sense in embarking on a project unless the quality of the product or service that results from that work meets or exceeds the expectations of the customer. Even if the project is delivered on time, within budget and with the defined scope, it will be a failure if the quality isn’t there. Quality should be considered from the beginning of the project and at the forefront of everyone’s mind throughout the project.
Quality is a fake forth factor in projects. The only 'quality' is that the technical performance is delivered when required to produce the return sought (they always go together). There is no separate 'quality' parameter!
If technical performance is not achieved, the project is not 'done'. "Quality" then becomes an irrelvant overlay.
For example, a door has to stay on its hinges and latch shut when closed. If it does not  do this, then it is not that it is a 'poor quality' door, but that it is not functioning as a door at all. There is no door if the lump of wood won't swing on hinges and latch closed.

Thursday, June 5, 2014

The project machine?

In his post on Better Projects Jon Whitty reports on a mini-experiment that he ran (write up here) on people's drawn responses to projects: kind of like art-therapy, I suppose.

He said:
What I discovered from this simple experiment is that our perceptions of project work is (sic) massively distorted by the various common artifacts (billboards if you like) of the project management community. The Gantt chart is a prime example. It reflects very little of the project experience ahead. An itemised to-do-list would do a better job. And in many cases I’ve found this is actually what is used.
It would indeed be a concern if people mistook the artifacts of project management for the conduct or the outcome of the project! It's also amazing that a gnatt chart and not a network of some kind is the representation of choice for a project's activity sequence.

If people are so wary of gantt charts, I am led to wonder if a quantified delivery risk is applied to each activity, or each work package, and if this is accumulated at stage gates for tracking (as per the critical chain method), and if there is a firm grasp of the outcomes and how they are to be firstly achieved, then measured. That is, what do we need to do and how do we know we've done it?

But, more than this disquiet, the enquiry betrays a machine view of projects, when this is as far off the mark as one can get.

It is naturally possible to model and run a project using some machine like representations, but these are only the documentation of a community process and represent an abstraction required for the organisation of the more intense and responsive discourse and joint action. And, no, I'm not going 'touchy-feely' in using this language, but being fair dinkum. A project is done by a collection of people, in various contractual relationships moderated by a joint desire for (mutual?) success. It is this informed interaction that gets projects done. It is the work of, what I like to call, a 'community of intent'; characterised by communication to find resolution and progress.

This has attracted various terms over the years, but I find the thinking that Hal Macomber used in his Reforming Project Management blog, and that David Ing at Coevolving Innovations refers to to be on the right track.

Just think about a project you've been involved in (I mean a serious project, not the kiddie stuff that recruitment agencies sometimes refer to): if it is anything like one's I've worked on, it is run by lots of meetings and less structured conversations, a zillion e-mails and phone calls, and a high degree of flux; sometimes at a frenetic pace. All this is done in the light of the theme expressed in the formal documents and representations; which, in a well organised project, will be updated continuously and in the light of the outcomes sought and risks met and dealt with.

In many ways this is like the work of general management (see Henry Minzberg's various writings on what a manager really does); its artifacts are similarly uninformative about the work: cash flow statements, production schedules and balance sheets; but few people mistake these for the business.

Jon gets down to the to-do list and hangs his hat on it. Well of course. Day in day out, its a simple list of what you need to do, or what the project needs to achieve that lubricates activity. In construction this is the 'look ahead program' (a similar concept is commercialised in the Last Planner method): the next two or three weeks' rolling schedule done in great detail to co-ordinate interfaces between work packages and project events.

In my experience a project is produced by the complex information flow between participants, organised, themed and paced by a set of artifacts that recognise the limits of information and contraints of risk properly quantified and expressed.

If you want to talk to upper management about a project, you've got to use risk talk and not let them get locked in to a too neat gantt chart that over-simpifies reality and ultimately mis-informs them. As Glen Alleman insists, quoting Tim Lister: risk management is how grown ups manage projects.