« Adrift in a Sea of Conflicting Priorities and Assignments? Here’s a Life Preserver!
Supporting Frameworks for Successful Program Management - Introduction »

Corporate Singularity Vs Project Multiplicity

March 30, 2008 | Author: admin | Filed under: Corporate Transformation

Corporate Singularity Vs Project Multiplicity
By John Bolden

Corporate Singularity is a dynamic state that is composed of two discrete elements. The first element is the ‘operating state’ of the organization right now. No matter how long it lasts, it is the status quo now and, there is only one. For the purposes of this exercise this is ‘what is now’.

The second element comprises multiple views of the ‘operating state’ of the organization as it will be in the future - one view for each business improvement or transformation project. These views of the organization capture what will be different as each project is injected, integrated or implemented into the organization. For future reference, each view equates to ‘what will be’.

As you read this passage, your organization is executing tasks in order to fulfill its prescribed mandate now and will continue to do so until the outcomes of the next project are integrated into the operating fabric of the organization. At that very moment in time in the future - perhaps an hour from now, a day or two, several months or next year - a new ‘what is now’ state will be created when a project changes the operating fabric of the organization.

This new ‘what is now’ state will be the status quo until the next project in the delivery pipeline attains its ‘what will be’ objective(s) by changing, adding or adjusting something or other, somewhere or other, in the organization.

This dynamic, constantly evolving view of ‘what is now’ and ‘what will be’ is Corporate Singularity. The volume and variety of differing dynamics that create pressure to improve, grow, strengthen, refine, streamline, stabilize or even protect the organization are not limited to just projects of import, size, cost or risk. All projects of any form, whether simple and localized in one small department or global in scope affecting most elements of the enterprise comprise corporate singularity. An organization will attain as many new ‘what is now’ states as there are projects across the breadth and depth of the entire organization.

If you were to use the concept of Corporate Singularity when setting strategy, planning and executing each and every business improvement project - you, the project, the organization and every other project will be far , far better off. Let me explain…

How big is your Singularity…?

Envisioning Corporate Singularity without visual aids will be easy for some while those of us challenged by the concept of imagining what is now, what was then, what will be and what is happening in between will definitely benefit from using a scratch pad to follow this example:

On a blank sheet of paper, draw a line down the centre of the page, this represents the ‘what is now’ state of your organization at this moment in time. It is the mechanics of the organization at this moment in time - it is the sum of processes, people, policies and paraphernalia that equates to everything the organization does in its day-to-day operation, now.

Consider all projects or initiatives of any type that are underway at this moment, in any part of your organization. Depending on where you work within your organization, your relative level in the hierarchy and your ‘need to know’ you may or may not be aware of the extent of project efforts across the entire organization.

One trusts that someone, somewhere, has full and complete vision of everything that is going on, project wise, across the organization…???

Set up a relative scale that accommodates both the duration and start/end dates of your projects. Draw a horizontal line for each and every project; position the left end of the line at the approximate point where the project first saw the light of day and the right end of the line at the point when the outcomes of the project are expected to be fully integrated into the organization.

You will end up with a collection of lines of varying length, each bisecting the ‘what is now’ line. If you know of future projects where the start date is to the right of the ‘what is now’ line, scribe them also if the width of paper allows. The left end (start) of each project bears a tag known as ‘what was then’ while the right end of the project (completion) bears a tag denoting ‘what will be’.

“What will be” is obvious, I hope. ‘What was then’ is a little confusing and while those who possess spatial dexterity will easily grasp the import, the rest of us deserve a brief explanation.

Corporate Singularity Vs Project Multiplicity

Look at my example diagram - the start point of each project underway has a tag known as ‘what was then’. This means that time has passed from when the project was approved or started (when the project started, it was at the ‘what is now’ line), the project is still underway and will address an issue or exploit an opportunity at some point (what will be).

What is crucial to note is the fact that multiple projects; each with different start dates, differing end dates and with presumably different objectives are progressing concurrently, albeit at differing stages, speeds and degree of importance, right at this moment in time - all busily focused on their own objectives, issues and problems.

For simplicity, my example denotes just seven projects. Vertical green lines denote the start point (what was then) and end points are denoted in red (what will be) for each project. (Note: I use dashes and dots to bring attention to green and red lines respectively, these formats have no bearing on the construct). Each project is shown in blue where the thickness of the line denotes the relative cost of the project.

The vertical lines are of different length and thickness. A widespread need across the organization = a long green vertical line; a concentrated or specific need in one area or part of the organization = a short green vertical line. Bear in mind, any green line means there IS an issue or opportunity that that project will address once the project reaches the ‘what will be’ point, a red line.

Similarly, if the need extends deep into the organization or is extremely complex = a thick green line, if the need is simple or generalized = a thin green line. The same logical representation appears for the red lines with the observation that in many, many cases the original assumptions in terms of width and depth of need (vision/green) bears no relation to the actual extent of change necessary to make the imperative work (delivery/red). This causes a significant number of project to miss expectations, for what I trust are obvious reasons.

Naturally, real projects would be much more complex to view with co-terminus, co-dependent, intertwined and staged projects all over the paper - yet this simple view of just a few projects allows us to probe several common ‘corporate singularity’ problems…

Baseline Disconnects; Incorrect Assumptions; Too Much Change; Reuse Anathema…

Look at the fifth project from the top of the diagram; I use a dotted line for clarity. What stands out? Let’s see:

Three projects started before this project and each of them appear to span or share some common elements of the organization (green line = vision/need or issue).

Is the fifth project replicating or duplicating part or all of any of these three projects? Can the fifth project use assets, collateral or knowledge from the projects already started? Could parts of the fifth project or parts of these other projects be cancelled, combined, consolidated?

What else should one be worried about…? Five projects in total will complete before the fifth project completes and two of these started after the fifth project.

Will delivery of these projects affect the operating fabric of the organization so that the fifth project’s deliverables will not fit or cannot be integrated easily?

Will the people in the organization be too exhausted to properly accept more change?

Will delivery of the fifth project render obsolete, unworkable or untenable the deliverables of the previous five projects?

Will the outcomes of the fifth project hinder or damage the prospect of success of projects that deliver later?

One project that started after the fifth project delivers after the fifth project is complete:

What might this mean to either or both projects?

What might this mean for the organization?

Is it safe to assume that the rationale for either or both of these projects will not be harmed or altered in any way?

Did anyone ask?

I leave you to imagine the possible permutations of additional questions that one would naturally ask and rightfully expect to receive clear and coherent answers.

Key Fact: The baseline for project assumptions about what to integrate, how and to what effect must be driven by assumptions about the ‘what will be’ state that will exist at the moment when your project outcomes are integrated into the operating fabric of the organization (future) and not by the ‘what is now’ state that existed when the project was conceived (past).

Let me explain this key fact further by way of example: Look again at the diagram; imagine you have an urgent business problem right now (’what is now’) and you plan to launch a project to fix it. Draw a project line from ‘what is now’ out to the point where the project will complete and the problem will be fixed (what will be), then draw a red vertical line of appropriate length and thickness that approximates the extent of change this project will bring to the organization.

Let’s say that your project line crosses four red lines already on the diagram that indicate that other projects will complete before your project finishes its work. Each of these four other projects will effect change in some way on part(s) or all of the organization. These four projects have each been working to resolve a specific issue or exploit an opportunity and what they change in the organization may well impact what you intend to fix or use to advantage…

Unless you know and cater for the full extent of what each of these other projects will change and what the sum impact of these changes upon the organization will be, you cannot envision and plan what your project will need to do, to whom, with what and with what intended outcome. Your business improvement project will not meet expectations. When planning your project, the fourth red line is the organization as it will be when your project completes. This fourth view of the organization is the view that your project must focus on, accommodate and plan for. Clear?

In general terms, this extract touched upon four ‘project failure’ themes:

  1. Project Baseline: Projects that use the incorrect baseline for planning purposes are doomed to fail before the project even commences.
  2. Project Assumptions: Projects that remain fixated on assumptions made at project start up fail. This speaks to the linear, insular, singular mentality of project management methods and practices. Projects of all sizes in all realms suffer from an inability to adjust the assumption set as time passes, events unfold and other projects enter the fray.
  3. Receptivity/Saturation: Projects are the result of imperatives, ideas, urges or impulses (vision) to improve or strengthen the enterprise. Vision rarely addresses or accommodates receptivity for change or the dangers of change saturation from too much change, too often. Receptivity and saturation issues cause projects to fail; overlooking the ability of the organization to accept, embrace and utilize change to advantage is fraught with peril.
  4. Reusability Potential: Reusability is a curious anathema. Actual reuse across the research base was abysmally low whereas reusability potential was ‘high / ultra high’ which means that opportunities to save time and money and improve quality and satisfaction were ignored.

If you would like to learn more about the seminar themes I speak to, types of consulting engagements and research that underpins my thinking, feel free to browse my web presence at http://www.TLIRGroup.com

John Bolden
RMA, Mil C, C/MBB-ISSSP. F-IICM, F-IPMS

Transformation Leadership, Innovation & Research
http://www.TLIRGroup.com

John Bolden is renowned for value laden advice that stakeholders depend on when assessing the wisdom of investing billions. John’s views and observations enable corporate leaders to ask the right questions, probe problematic answers and avoid surprises.

Share this article:
  • StumbleUpon
  • Digg
  • del.icio.us
  • Technorati
  • Reddit
  • YahooMyWeb
  • blogmarks

This entry was posted on Sunday, March 30th, 2008 and is filed under Corporate Transformation. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories