Good article, including the simple fact:
In the industrial company of the future, there won’t be a separate IT department.
From: http://www.strategy-business.com/article/The-Thought-Leader-Interview-Bill-Ruh?gko=9ae51
Category: Transformation
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 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.
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.
You’ll find yourself focused on one of the following types of transformational change:
- Strategic Pivot
- Continuous Change Culture
- Innovation Injection
- Prepare / Response
Process:
- Make a decision along each edge
- If you can’t make a decision perform the recommended step
- Choose the quadrant where your highest concerns converge
- Follow the arrow to determine order of sub-initiatives
For example:
1) If you’ve had a recent change of strategy, and your see the posture of strategic as something that enables agility you will find yourself in the “Innovation Injection” quadrant. You first sub-initiative will be a Prepare / Response to a particularly pain point.
2) If you find that you business-as-usual operations can’t absorb the sort of change your customer demand you’ll find yourself in the Prepare / Response quadrant and your first initiate will be to create a culture of continuous change.
Good overview of how the business architecture discipline bridges the strategy / executive gap (i.e. transformation)
With this year the year of capability engineering I spent last night building out a simplified maturity model for how new business capabilities might evolve. This model is a lot of thinking packed into a single artefact, and still a work in progress.
Note: this business capability maturity model is used within MWT Transforms.
All new business capabilities got through a number of maturity levels before they are a recognised capability of the organisation. Aspirational capabilities identified and sponsored by the executive team also go through the same journey; however, there is in this case greater visibility of the progress through maturity levels to the executive team.
Level 1 – No capability
No formal capability exists. Although competencies may exist in the organisation there is:
1. No explicit decision on the level of standardisation / centralisation required.
2. No formal accountably for the capability within governance structures
3. No agreed understanding of the capability and how it contributes to the operating model at the executive level
4. No explicit references to the capability in strategic planning (or equivalent) processes
5. No understanding of how the capability contributes to the product strategy or to the development and delivery of products / services
Level 2 – Isolated capability
An isolated capability exists. This isolation can appear in any or all of the following dimensions:
1. Isolated application of the capability to solve a single or small number of business problems
2. Recognition of duplication where superficially similar pockets of capability are identified throughout the organisation but they are isolated from one another
3. New or business critical application of the capability is built or identified but considered an exception to one or more policies, standards, or organisational behaviours despite having clear business benefits
Level 3 – Servicing capability
Integration of an isolated capability with the organisation begins with establishing service managed around the capability. This creates dependencies with other business units and makes the capability critical to operations.
The use of service management principles achieves the following:
1. Creates internal “customers” for the capability
2. Allows the operation of the capability to be separated from the services; providing an opportunity to leverage the services of other business units to deliver the capability’s services.
Level 4 – Strategic capability
The executive team explicitly reference the capability during decision-making and the strategic planning (or equivalent) process.
Level 5 – Differentiating capability
The relationship between the capability and how the capability contributes to the product strategy and to the development and delivery of products / services is managed.