“That Taylorism and its modern variants are often just a way of putting labor in its place need hardly be stated: from the Hungarians’ point of view, the pig iron experiment was an infuriatingly obtuse way of demanding more work for less pay. That management theory represents a covert assault on capital, however, is equally true. (The Soviet five-year planning process took its inspiration directly from one of Taylor’s more ardent followers, the engineer H. L. Gantt.) Much of management theory today is in fact the consecration of class interest—not of the capitalist class, nor of labor, but of a new social group: the management class.”
Page 2 of 20
This is an article I wrote around 2002 that was eventually published on the Satyam (new Tech Mahindra) blog. I can’t find the old Satyam blog now so here it is again.
Projects, Programmes, and Work streams (Part 1)
MegaProjects are large enough to be called a ‘programme’, but integrated enough to be called a ‘project’. In the end, all MegaProjects must be run as a programme; but it’s important to understand why. This is a slightly edited reprint of an article I wrote on delivering technology-enabled business transformation (TEBT) projects which describes the difference between a project and a work stream; and the challenges for project management on MegaProjects.
If you talk to a project manager or a programme manager for long enough you risk getting into a very long conversation about the differences between project management, programme management, and portfolio management. It’s easiest to define these first in terms of what a project is and secondly in terms of the objectives for grouping projects in certain ways:
1) A project utilises resources, has a specified duration, and delivers pre-defined objectives
2) A programme is a group of projects which are managed together as they relate to the same objectives and there are interdependencies between each projects’ deliverables
3 )A portfolio (of projects) is a group of projects which are managed together because they are part of the same organisation and therefore must have sufficient consistency in the way they are managed in order to manage resource allocation across projects, and risks across that organisation
There are added complexities around the definitions of operational vs. strategic programme and portfolio management. Management of the dependencies between each project is separate from the management of the mix of projects in the programme or portfolio itself. In other words, there is a difference between running a group of projects right (operational) and investing in the right group of projects (strategic). For MegaProjects their duration means a certain amount of the strategic process is required, but we are focused here on the operational side of MegaProject management.
So is a MegaProject a project, or a programme?
MegaProjects have two important characteristics that make them a unique challenge to the project management discipline. Firstly, MegaProjects are indeed projects because they share a single set of phases and milestones and all resources will be affected in some way be the overall project lifecycle. Secondly, MegaProjects must be managed as a programme in order to balance the need to manage accountability for deliverables within each part of the project and the need to manage dependencies across each part of the project.
Ultimately, all MegaProjects must be run as a programme. However, although each MegaProject must be run as a programme this isn’t because MegaProjects are a collection of projects. MegaProjects must be run as a programme because they will require more than one project manager! This is a vitally important point that shouldn’t be under-estimated. MegaProjects have objectives that are significant in scope and therefore are sufficient to require multiple project managers to deliver them. It is for this reason alone that you must run MegaProjects as a programme.
Project managers behave in predictable ways: they want to define the criteria for success at the beginning of the project, they want to manage scope, and they want to freeze requirements at a certain point. They will also expect access to the valuable time of stakeholders and subject matter experts. For regular projects, all of these behaviors bound and align a project in order to improve the odds of the project being successful.
These behaviors are the basis of good project management. However, MegaProjects require additional monitoring and control mechanisms to ensure that these behaviors don’t guarantee success of part of the MegaProject at the expense of failure or bottlenecks in another part of the MegaProject.
Projects vs Work Streams
One of the keys to a successful MegaProject is correctly identifying which parts of the MegaProject are projects and which parts are work streams. These projects and work streams can then be aligned through key programme-level processes which cross both types of activity.
Next week’s article focuses on the differences between projects and work streams and how to define these within a MegaProject…
Projects, Programmes, and Work streams (Part 2)
In part 1 we saw that MegaProjects must be run as a programme primarily because multiple project managers will be required in order to execute the project. Project managers behave in predicable ways and will try to manage the scope of their deliverables in order to achieve success for their part of the MegaProject. To ensure success of part of the MegaProject isn’t at the expense of other parts of the MegaProject this article introduces the difference between Projects and Work streams.
Difference between projects and workstreams….
- Scope tends to exist within only one or two areas of the TEBT programme planning worksheet
- not directly connected to the objectives of the programme
- fed work from other part of the programme in terms of level-2 requirements, defects, analysis requires, etc
- managed as a ‘cost centre’ in that resources are fixed or leveraged as a pay-per-use managed service with a fixed budget
- responsible for defining resource requirements based on solution
- directly accountable to objectives of the programme
- scope defined across the business transformation objectives and at least 2 layers down the TEBT programme planning worksheet
- utilises work streams for input or delivery of defined work packages
- responsible for defining resource requirements based on objectives
The TEBT Programme Planning worksheet also defines (on the left) some functional responsibilities (such as testing and implementation) which are by definition work streams.
Mention the programme phases, milestones, and the delivery roadmap… future post.
Relationship to SDLC
While it’s true that each piece of code must go through a software development lifecycle; pieces of code will be changed for the duration of the project so the programme itself is never at a stage in the software development lifecycle. Also, MegaProjects produce many deliverables which are not code but that have relationships with code (and other deliverables that must be managed).
TEBT Programme Definition Worksheet
Part of the delivery roadmap for the overall programme
- oDefine objectives, budget
- oDetermine partners and capabilities required
- Solution Blueprinting and Delivery Roadmap
- oDefine a cross-partner solution
- oDefine a delivery roadmap
- Project & Workstream Definition
- oDevelop project and work stream accountabilities
- oDevelop charters per project and work stream
- Analyse and Planning per Project / Work Stream
- oAllow initial analysis to complete for each work stream and project
- oConfirm resource requirements
- oConfirm dependencies across projects and work streams
- oDefine shared programme level processes
- Development of Deliverables
- oDevelopment of deliverables for each work stream
- oExecution of shared ‘Development’ programme level processes
- Integration of Deliverables
- Test execution
- Integrated test management
Vendors may join or leave at various phases.
Interesting to see the progression of ideas from academia through to government.
Take for example “cognitive biases”:
- 1972 – Academic work – “The notion of cognitive biases was introduced by Amos Tversky and Daniel Kahneman in 1972” from here.
- 2011 – Popular work (~40 years later) – ““Thinking, Fast and Slow” spans all three of these phases. It is an astonishingly rich book: lucid, profound, full of intellectual surprises and self-help value.” – from here.
- 2015 – Mainstream in business (?) (4 years later) – “research suggests that there are a number of cognitive stumbling blocks that affect your behaviour, and they can prevent you from acting in your own best interests” – from here.
- 2016 – Government (impressively, only 1 year later) – “As human beings, we think we make rational decisions every day, but in fact, we’re all seeing the world under a set of behavioral illusions that can really muck up our decision making. These are called cognitive biases” – from here.
Well done to the DTO folks for making that last leap impressively fast.
Marketing people are familiar with funnels – though there is also a funnel backlash – but this is a good example of the principle applied to obtaining investment:
Henry Mintzberg just mentioned on LinkedIn that “Power In and Around Organizations” is available for free here:
Always a good read.
Capability-based Governance and business architecture:
The McKinsey Podcast has a great summary of “digital”. It’s basically a summary of good stuff that’s been around for a long time:
- Optimise assets
- Use data
- Optimise decisions-making (both bold, and common)
- Improve intimacy with customers
- Agility as responsive but with a stable core
- Radical cost reduction – including elimination of processes * Two speed IT architecture
- Bringing in talent from other industries… Works to a point
- beyond org charts and focusing on coherence
I’ve been reluctant to call what I do “digital” but if might be time to admit I’ve been “doing digital” for some time.
There are of course some universal truths here that have just been rebadged as “digital”. The idea that you should allocate resources to things that you believe will be required in the future and reduce your allocation of resources to things you don’t believe will be required in the future is important but has very little to do with digital.
I also noticed that the two interviewees seemed to disagree slightly on some points and were holding back from a debate. Maybe that was just me.
Podcast episode here: https://itunes.apple.com/au/podcast/the-mckinsey-podcast/id285260960?mt=2&i=360547521