Sources of complexity

• Is your programme, project or work package complex? How do you know?
• Is your “complex” project as complex as mine?
• What aspects are complex? What does that mean in terms of the management and selection of people?

The fundamental reason for undertaking any work is to realise benefits for an organisation and its customers. To do this, an organisation needs to apply the right solutions, processes, methods and people. Yet, as no two pieces of work are the same, how do we understand the nature of complexity and select the right people for the job?

On the flip side, the cost of NOT understanding complexity can be serious, leading to over optimism, broken promises and disappointed stakeholders.

A COMPLEXITY TOOL
The primary use for a complexity decision support tool is to help managers to match the level of experience and skills of assigned manager to the demands of the work required, by understanding:

the type of work and how it is best managed (as a work package? A project? A programme phase? A programme?)

the sources of complexity from which risks may be derived which threaten  business success in relation to the work

Such a tool should not make decisions for you but rather, helpmanagers make the right choices by highlighting key aspects which lead to complexity.

SOURCES OF COMPLEXITY
Sources of complexity include:

Business criticality: This factor addresses the alignment to strategy and the importance to the business of completing the work. The more critical the work is to the organisation, the greater the management attention should be.

Reputation exposure: Even the cheapest, smallest work can have a catastrophic or beneficial impact on an organisation’s reputation which, in turn, can impact sales and business survival (the Ratner case is a prime example).

Business transformation: This factor addresses the transformational change challenge required in the work in terms of culture, people and processes. The greater the transformation needed, the greater the challenge and complexity.

Legal, contractual and regulatory exposure: This factor addresses the potential legal, contractual and regulatory impact on the work. Work undertaken in a highly legalistic or regulatory environment has a greater number of constraints which need careful management. Breaching these constraints may lead to damages or penalties.

Schedule flexibility: This factor addresses the criticality and flexibility relating to the schedule. Some work schedules may be negotiated or have significant float within the context of higher level work. Others are constrained by contracts, which may be negotiable, whilst in the extreme, some are constrained by immoveable events.

Requirements and scope: This factor addresses the degree to which the vision, requirements and scope are defined at the outset. The less well defined these are, the greater the potential for scope creep, misunderstandings and disputes. Specific management techniques need to be used and agreed for such risky situations.

Output Innovation: This factor looks at how standard or novel the output from the work is. The development of completely new outputs requires a higher level of expertise and management than ones where standard approaches are used.

Delivery processes: Most programmes and projects require more than one management or delivery process or method. This factor addresses the maturity of the ones being used. If the processes and methods are well tried and tested, then the work is less risky. If new processes and methods have to be developed for the work, that makes the undertaking more complex.

Financial exposure: This factor addresses the extent to which an organisation will benefit or suffer from the work. Some work is “within the noise” of the overall budget, whilst other work is highly visible in the formal accounts.

Inter-dependencies: This factor addresses the number of interdependencies into and out of the work. The greater the number of dependencies, the more constraints there are and the more risky the work becomes as such dependencies cross managerial boundaries.

Team dynamics and size: This factor addresses core team size and dynamics. The smaller and less dispersed the team is, the easier it is to manage and have effective communication. The larger and more distributed the core team, the greater the effort needed to keep the members aligned.

Supplier involvement: This factor addresses the degree of reliance on suppliers and includes such aspects as number of suppliers, reliability of supplier and experience with those suppliers to date. In these terms, “suppliers” can also include separately directed lines of Business or divisions.

WHAT ARE YOUR VIEWS AND EXPERIENCES?
If you have any views, observations, experience or suggestions on complexity, feedback through this blog.

To the War Room!

A rather large, programme was having a bumpy time. The customer wasn’t happy and wanted ACTION NOW to sort a few things out.

So the programme manager decided to clear a meeting room and allocate it to the “right” people who were dedicated to solving the issues. The room was taken off the “meeting room rosta”, white-boards, post-it stickers, large TV screens and other things were installed . . . . and a lovely notice saying “War Room” was put on the door.

A week or so later the customer’s senior representative was visiting the office to see how things were going and stopped by this door; ” . . . and who, precisely are you at war with?” was his question.

Hmmmm. Perhaps we’d better think up a name for these facilities, which better reflects the use of such rooms and the message we want to convey.

What would you call it? All suggestions, welcome.

How do I know it is a “good one”?

Make your information count

Programme and project management relies on information, much of which is contained in documents and tools. Good practice (and indeed common sense!) says that a deliverable needs to be verified to ensure it is fit for purpose. So, for example, software deliveries are verified through formal testing. Documents are “reviewed” by the appropriate people before they are approved. But who are the “appropriate people” and what are they looking for when they review a document? How do they know it’s a “good one”?
Good documents as a basis for rigorous decision making and baseline management
Most programme and project management information is contained in documents. All the key ones are defined in templates, which act as a prompt to the author to ensure the right information is included. Templates also ensure there is consistency in terminology and approach, so that the people who review the document (and later approve it) don’t waste time resetting their brains to yet another “way of doing things”. The documents form the basis for decision making and for setting baselines. Good documents lead to more rigorous decisions and control.
The product description as a key enabler to “good”
Coupled with every significant template you should have a “Product Description“. This is a technique taken directly from PRINCE2 which helps ensure the documents which are produced are fit for purpose. The product descriptions contain key information defining:

• composition what the deliverable is made up of
• quality criteria which can be used to judge if the deliverable meets the need
• review skills, suggesting what skills reviewers need to have if they are to be effective
• tailoring guidelines, which say how you can change the template to suit your particular needs.

By including standard product descriptions in your enterprise approach, you can save your company time as your people do not need to develop their own each time.

What on earth is a “Workstream”?

A lot of my colleagues thought this would be a good topic for a blog. Do you know what a “workstream” is? Does everyone have the same interpretation of that word? Are you sure? I assume someone, somewhere does, as it is used very widely in many companies (probably driven by some consulting organization!).
Some quick research
I did some quick research and found that this word does not exist in any formal project management methodology (for example PMI, APM, DIN, PRINCE2).
The often quoted Max Wideman glossary makes no mention of it.
A quick scan of the web comes up with comments like this, which was in response to a person asking what the Spanish for “workstream” is:
My guess as to why you are having difficulty pinning down the meaning of the term “workstream” is this extract from a response to a forum question:

I think it is a proper name of various businesses and software packages which is gradually leaking into professional jargon for more general use. I think “workstream” has not yet reached the status of a real word with a settled meaning. I won’t go so far as to suggest that it is meaningless, pretentious jargonspeak. But . . . .

It can’t be translated! This rather explains why, on my work on the new international standard on project management, I haven’t come across it. The International Standards Organisation (ISO) only uses plain English terms from the Concise Oxford English dictionary, which are translatable. The Project Workout is aimed at international readers and so I have taken the view that everything in it should also be translatable.

Even Microsoft Corporation, that great source of jargon and acronyms, doesn’t include the word in its spell checkers.

Looking at real organisations, I have identified “workstream” to be used synonymously with a “department, function or directorate” and a “sub-programme”, which are entirely different dimensions in the classic organisation matrix. I also found it was used to group together virtually any number of unclassifiable clusters of activities.
The Project Workout
The Project Workout does not contain the term “workstream” for all the reasons given above and yet it is in common use, We are not living in George Orwell’s “1984”, so you can use the term “workstream” if you really want to, but if you do use it, consider exactly what you mean and what management procedure would be used to manage it; if you can’t determine that, then you can’t expect anyone else in your team to understand you.

My advice – don’t use it!
I am sure people will still use the term, perhaps because it is such excellent fudge or perhaps it just sounds “cool”, “techno” or even “heroic”! My advice is to avoid using the word, when we have well defined, plain English, alternatives. What do you think?

When a plan is not a plan at all!

The word plan is used frequently in day to day conversations and most people have a good idea of what a “plan” is. However in a programme and project management context things may not be quite so clear. One common mistake people often make is to believe the “plan” is just the timescale, as shown in a Gantt Chart. However, whilst the timescale (or schedule plan, to give it its formal name) is vital, it is only one part of the overall plan. The other aspects include:

• costs,
• resources,
• accountability,
• WBS
• and, often, benefits.

These are often bundled together into a narrative document such as a Programme Plan or Project Plan.

This holistic view of the term “plan” is what is used in PRINCE2, BS6079, PMI and APM publications . . . and that is also how we use the term in the Project Workout. You can find out more about planning in the Project Workout, Part 4.

Good programme and project plans can take many forms and any enterprise approach should allow a programme or project manager a wide degree of freedom in how to document this. Standard Product Descriptions, which contain tailoring guidelines are good place to document such guidelines.

So, next time you are asked for a “plan”, check what the person is really looking for and don’t jump to conclusions that what you define as a “plan” is the same as theirs.

What is a project? (groan)

When I hear this question at a seminar or conference, my heart usually sinks. Here we go with a lot of pedantic waffle. “ start, end, unique” etc. In a general sense (and seminars and conferences are nearly always “general”), the precise definition of a project doesn’t really matter. Most people attending such events have enough of an understanding otherwise they probably wouldn’t have signed up. However, start moving into the context of enterprise-wide project management and the use of a term such as “project” can make a lot of difference.

Buttrick’s first law of naming: Anything called “xyz project” might actually be a project. Anything called “Project abc” probably isn’t!  It is just that some people think its sounds cool and modern to write backwards.

But my project isn’t like that?
If your idea of a project is different from mine then we could get into a bit of a muddle if we tried to work together. At one end of the scale we have the “school project”. Is full scale “project management” the right procedure for your kids to use to manage that? Absolutely not! Closer to the work place, I expect you’ll find that there is a lot of work undertaken which people call “projects”, but which in reality are bits of projects.

What! You want me to write a Proposal and a Business Case/Project Definition, get a sponsor, set up control logs, provide progress reports, do a bit of stakeholder management etc etc ,when all I am doing is installing a new server. I always knew this project stuff was an administrative nightmare!

Often these are simple “initiatives”; for these, the use of full scale project management would be a huge, non-value added overhead. (This is often where Agile techniques are used or in many cases where routine operational processes are needed). If full scale project management seems like overkill for your “project”, then consider whether the work you are doing is a project at all. It might be a work package and so a simpler approach, using key project management techniques, such as planning, may be more appropriate.

Understanding the difference
The glossary in the Project Workout defines the terms. Both projects and work packages have a start and end etc. but there are TWO important differences:

• Projects are aimed at a achieving a stated business objective, as opposed to contributing to a lot of other stuff, which when put together enables an objective to be achieved.
• Projects have to have a staged lifecycle, which is used to manage risks. Project work is risky enough to warrant a senior management decision prior to starting each stage. The riskier the work, the more stages there are. I have seen 12 stage lifecycles for projects relating to key aircraft components, which if they failed would cause the aircraft to crash. Work packages can be approved as a single lump. Project lifecycles are not development processes, where the stages are based on technical content. See the Chapter 3 of the Project Workout for more on this.

So, when you find yourself thinking that that “project management” is too heavy, it may be that your work is better described as a work package, which has a simpler management approach.

Think about this

1. Just because a person who is called a “project manager or director” is doing the work, it doesn’t make that work a “project”.
2. Cost is a very poor indicator of the size or complexity of the work. One person’s work package may dwarf another person’s project in cost terms.
3. The “real work” happens in “work packages” managed by team managers who are skilled and competent in the work outputs being developed, not necessarily project management.
4. Team managers (all managers!) require a minimum level of project management skills, even though they may NOT be “project professionals”.

Where to find more in the Project Workout

Chapter 3 is where you will find out more about projects and the importance of project lifecycles.