Operations management

During my Christmas break, I've been exploring videos on operations management. Whatever your field: architecture, engineering, project management, construction, icecream distribution, you manage operations.

So, I went to the experts.

Lisa Bussom at Widener University, Eddy Witzel, and Inderdeep Singh at the Indian Institute of Technology.

I'm working through Lisa's content first.

In the second lecture, she talks about product 'attributes' and includes 'quality'. Quality is conformance to specification, in conventional conception. And sure, that's broadly an attribute of a product, but I think it is better to go to why the customer has an interest in the particular specification. They want a level of performance that will meet their need, their requirements, and give them value.

Performance is the attribute.

This then feeds into the process 'competencies'. Lisa has 'quality' as a competency. I would substitute 'design' for this.

Design is the threshold input to an effective process.

The genealogy of value is this: customer need/opportunity > performance to meet the need/take the opportunity > requirements to produce the performance > specification of capability > design to meet the specification, deliver the capability, produce the performance to deliver value to the customer!

Best practice?

Really? Best for whom?

I'd prefer to develop my project practice in Deming's cycle; therefore, not 'best practice' but 'better practice' better for my projects in my circumstances. Using someone else's 'best' ties me to their past, not my future.

Project method

Project management 'methodologies' come and go; or more to the point, come and stay, competing for our attention.

In some places I use the Prince 2 method: which can become excessively cumbersome if the PM doesn't 'nimble-ise' it.

Some people regard PMBOK as a method. It is not. Its a list, a conspectus of project management, not always particularly helpful for the practicing manager.

I like the Project Success Method (not the snappiest name), but it nicely combines good theory, good practice and good teaming, all woven into a practical doable and very scalable approach to projects.

There are four basic components to it, using interactive team processes (reminiscent in my practice of using Value Management type workshops throughout the project, from commencement to progress reviews). The four components (1-4) then lead to the activating processes (5-7).

1. Develop a project charter
2. Define the work (using a work breakdown of whatever detail is useful)
3. Set activity relationships in a precedence network, setting the critical path/s
4. Prepare a schedule (time the activities on the basis of minimum cost per activity)
5. Compress activities on the critical path on the basis of cost of compression vs money saved/expenditure avoided. Keep cycling through this until all beneficial compression has occurred. This forms the baseline schedule.
6. Update the schedule on the basis of 'expected to complete' dates.
7. Review the network, re calculate the critical path, check for end date against baseline end date, and compress on the critical path again if necessary. Or, re-work the network to shift the critical path.

My own contribution:

Where possible include risk probabilities and use reference class experience in estimates to give an (agreed) 85% probability on meeting the estimate (the particular level of probability depends on the circumstances, of course).

This can be elaborated up or down depending on the size of the project, the management overhead capacity and sophistication of analysis available (earned value).