Mega Projects Redux: Projects, Programmes, and Work streams (Part 1 & 2)

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….

 

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

 

Projects 

  • 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

 

 

See  www.managewithoutthem.com/tebt/workstreamsandprojects.html

 

 

TEBT Phases 

 

Part of the delivery roadmap for the overall programme

  • Initiation
    • 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
  • Implementation

 

Vendors may join or leave at various phases.

The No ICT Strategy Organisation

The idea of business / IT alignment is completely at odds with the challenge of business agility.  You can never align all-of-the-business with all-of-the-IT.  You can only ensure that the business capabilities your organisation’s operating model depends on sufficiently utilise information technology in order to ensure competitive levels of productivity, optimal customer experience, and coordination with other business capabilities.  
 
The idea of business / IT alignment is admirable when it implies that in model business operations there is a concept of “business” concerns and their is a concept of “IT” concerns and that they are peers.  The process of business / IT alignment then would be a messy and complex process that might eventually work.  However, business / IT alignment never gets implemented as a process that assumes business and IT are peers.  Even if it was, it’s foolish to break your organisation along the lines of business versus IT – there are other ways of cutting up the organisation that eliminate the need for business / IT alignment altogether.  
 
This is further exacerbated by the shift of IT budget to business units.  Once budget that had traditionally been thought of as IT budget gets shifted into, say, marketing, it would be ridiculous for the marketing department to then raise a concern about the business / IT alignment challenges they were having when spending their new increased budget.  Once you’re responsible for both why complain about alignment?  If you own the budget you have nobody to complain about business/IT alignment to.
 
I’ve written before about how much of what people in the so-called “business” think of as “IT issues” are really related to information, complexity, or simply willingness to spend time on the details.  When a business process is automated – does it then become an IT problem?  It is a sign that our understanding of the dynamics involved in the implementation of information systems – which it is now trendy to call “digitisation” – has certainly outpaced our popular understanding of how organisations are designed and governed when these simple questions still have complex answers.
 
We have a number of real problems governing our organisations.  Business and IT concerns aren’t ever broken down to specifics, the whole concept of splitting business and IT places barriers to true organisational agility, and there still isn’t an understanding that in the modern world the high-level concept of “the business” and “IT” don’t exist.  This separation is make for the convenience of executive leadership and have limited organisational value.  
 
I’ve previously proposed the simplest change might be to stop creating ICT strategies.  I’m not saying an overall strategy for certain aspects of IT isn’t required.  I’m simply saying that an overall strategy for the organisation is more important.  If you have a business strategy and an ICT strategy is it any wonder you have business / IT alignment issues?  Of course you have alignment issues!  You have two seperate strategies. 
 
This is exacerbated by the fact that your business / corporate strategy  probably doesn’t contain the sorts of things the folks developing your ICT strategy expect to see anyway.  They probably have to go to individual business unit strategies to get the information they need and ultimately the ICT  folks are left to try and align the inconsistencies that will inevitably exist between all of these business unit strategies.  
 
A strategy development and strategy deployment process grounded in business capabilities is of course the answer.  

The path from academic to mainstream – Cognitive bias

Interesting to see the progression of ideas from academia through to government.  

Take for example “cognitive biases”: 

  • 1972Academic work – “The notion of cognitive biases was introduced by Amos Tversky and Daniel Kahneman in 1972” from here.
  • 2011Popular 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.
  • 2015Mainstream 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.
  • 2016Government (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.

Good examples of the “funnel” pattern

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:

https://soundcloud.com/keypersonofinfluence/kpi-matthew-michalewicz

Free Henry Mintzberg!

Henry Mintzberg just mentioned on LinkedIn that “Power In and Around Organizations” is available for free here:

http://digitool.library.mcgill.ca/R/-?func=dbin-jump-full&object_id=134841&silo_library=GEN01

Always a good read.

Is Velocity Killing Agile?

Is Velocity Killing Agile?

This is a perfect example of the MWT principle of the need to “separate measurement from management”. On an unrelated note it also reflects my belief that the “agile” movement is its own worst enemy – because it think it’s managing a broader scope of organisational decison-making than it actually is.

Capability-based Governance and business architecture

Capability-based Governance and business architecture:

http://www.strategy-business.com/article/Enterprise-Architecture-Planning-2.0?gko=43bf5

 

Getting closer to the future of the IT function

My views on business capability-based governance extend to the idea that an “IT function” doesn’t really make any sense at the highest governance levels.  However, the implications of this are significant.  So, in the meantime….

McKinsey on Digital

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

 

Capitalism Epochs and Pendulum Arguments

I have long been interested in pendulum arguments. These are the sort of arguments where the position swings drastically from one position to another. For example, capitalism versus of socialism, centralised versus decentralised, or technology-driven change versus business-driven change.

I think these pendulum arguments ultimately turn out to be false dichotomies or otherwise the result of incomplete models. Like real pendulums, they can be stopped by adding a “third thing”. Imagine the image of a pencil being stabbed into the middle of the pendulum which dramatically stops it swinging.

This “third thing” is usually something that is not typically considered part of the domain of the argument. It changes the model.

I’m finding this talk interesting, with the key slides reproduced below:
https://youtu.be/Yvv178OgB6E

The idea of “financial capitalism” versus “production capitalism” is a likely controversial tweak to our idea of capitalism.  The model appears to fit:

2016-01-18_11-27-36

I have a bit of an ideological issue with the other that the switch to the “deployment” / “production capitalism” phase “doesn’t happen automatically – i.e. that it requires governance help.  I suspect that this is a causation versus correlation debate.  Possibly Carlota is playing to her audience.

Page 1 of 19

Powered by WordPress & Theme by Anders Norén