Month: April 2016

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

By mdegeorge

On April 15, 2016

In Business Architecture, Capability Engineering, General MWT, Information Management, IT Management, Technology-Enabled Business Transformation (TEBT), Thought of the day, Transformation

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.