What is a Project Construct?

The purpose of a project construct is to plan and execute the changes that Org must make to stay relevant. The future is uncertain. Therefore, a primary task of this construct is to reduce uncertainty of a future outcome. In so, Org must effect change at minimal risk.

To reduce the uncertainty of an outcome, one must control the process that creates the change. If such change is beyond the day-to-day operational cycles of Org, then one would need to engage with activity beyond normal process flow. The goal of the engagement will be to begin, fix, or end a process. This is a once-off intervention. To create the future is therefore a project.

Project management method is currently the best way to implement organisational change. The logical design of a project minimises the risk of exceeding time and resource boundaries. Unlike a process, the value of a project only becomes known once it is done.

To execute projects, Org must take resources from its operational processes. Therefore, cost and time are the greatest risks to organisational change. The probability of these risks will increase if the change does not contribute to the intent of Org. Therefore, a well-defined project construct will reduce the risk of irrelevant operations. I.e., the aim of a project construct is to keep Org relevant.

Basic assumption of a project construct

A project construct drives the strategy of Org. If the purpose of strategy is to keep org relevant, then a project construct is a blueprint of the change that Org wants to affect. Although relevance per se does not directly imply change, the need to stay relevant does.

To understand a project construct, one must grasp how it differs from a process construct. This understanding will help us to create, change, and implement a project construct.

Project Management History

Project management began with the work of Frederick Winslow Taylor's on scientific management. This was in the early 1950's. His theories led to many modern project management tools. Some of these are the work breakdown structure (WBS) and resource allocation. Two students of Taylor were Henry Gantt and Henri Fayol. Gantt later became the father of planning and control techniques. His most renowned model was the Gantt chart. Fayol created the five management functions. These functions form the foundation of the project management body of knowledge (PMBoK).

In orgamatics we still use these project management methods. In fact, we encourage them, especially in fields such as strategy implementation. The difference lies in the way we connect all projects within Org to achieve its vision. From there the name "Project Construct". It is a network of projects that aim to ensure that the organisational processes stay relevant.

The project construct translates a utopian dream (vision) into a series of super goals. These goals are achieved through strategic objectives. Each objective becomes a program. Org will execute these programs through several projects. A project construct thus links all the activity that brings about change into one network, which links to one organisational vision.

The difference between a project- and a process- construct

Purpose begins and runs a process construct, whilst intent begins and drives a project construct. That is their primary difference.

"Life span" is the easiest way to separate the two. A process construct facilitates permanence. It creates operations and facilitates the performance of Org. The aim of a process construct is to repetitively cycle activity. It therefore consistently produces outputs.

A project construct drives execution. It creates strategy that strives to keep Org relevant. The aim of a project construct is to negotiate a favourable outcome for Org. In so, it must ensure that Org carries out its intent at a minimal risk. A project construct is thus a SMART transformation process. SMART stands for specific, measurable, achievable, relevant, and timeous.

The table below gives an idea of how a process- and project construct differs.

Engineering the project construct

A process construct connects all the processes within Org. In so, it creates an interdependent network of repetitive activity. This is something permanent. Projects are not permanent. They begin an end as needed. The need for change drives the project construct. Once effected, change will become part of the process construct. To engineer a project construct means creating something that is not permanent.

The purpose of any project is to begin, fix, or end a process. To end or fix a process, one must link a project to the effected process. E.g., If Org must create a new procurement process, it will launce a project to do so. This project will thus be linked to the organisational supply chain process. The same will happen if Org wants to end the current procurement process. But, if Org has no marketing process, and wants to create one, then there might be no current process to link with. In such case, we must link the project (to create a marketing process) to an organisational system. In an earlier essay, I have explained that to control a process construct, we divide the organisational purpose into systems. A system is a container for all processes with similar purpose. E.g., Procurement, recruitment, and budgeting processes all have the purpose to bring resources into the organisation. Their joint purpose thus makes them part of a resources system. In so, marketing has the purpose to attract new relationships with Org. Sales, CRM, employee relations, etc., do the same thing. Therefore, they are all part of a relationship system. So, if we must create a new marketing process, we will ignite a project and link such to the relationship system. This is where the design of a project construct goes beyond the normal boundaries of project management.

The relationship between a process and a project construct is thus dual and not linear. The one runs the business, whilst the other changes the business. One directs performance whilst the other drives relevance. I.e., they co-exist - one gives meaning to the other. They have an integrated hierarchy, yet one is permanent and the other not.

The project construct must pollinate the process construct. Its task is to begin, fix, or end a process. Projects will come and go as needed. Unlike that, processes will continue to cycle without an aim to end. The sketch below shows how a project construct interacts with a process construct. The black circles depict the hierarchical structure of the process construct. The top circle is the core process of Org. Its hierarchical branches help us to grasp its complexity. The white circles show the project construct. It latches onto various processes within the process construct. This is so that it can use resources from the process construct until it has done its task. When executed, the process construct will regain full control of its resources. It is a symbiotic relationship.

A project is born from a process construct. When its work is done, it will assimilate back into the process construct.

"…do your work, then take your hat…"

- Henry David Thoreau

The mechanics of a project construct

The task of a project construct is to organise all the non-repetitive activity within Org. Intent creates a need for change. This is because intent is a desire for a reality that does not currently exist. To create a new reality, one must do something. Once the new reality manifests, there will be no further need for change. You have arrived. To stay within this new reality, one must maintain it. To do so, the new change must be internalised into a process construct. I discuss the mechanics of a process construct in an earlier essay. Therefore, the first component of a project construct is "intent".

To execute well defined intent, we sub-divide it into a few objectives. E.g., if my intent is to lose weight, then my objectives might be:

1. To go to the gym four times per week for four months.
2.  To cut starch and sugar from my diet.
3.  To renegotiate my relationship with food.

Intent is where one wants to go, and objectives are how one will achieve that. Intent differs from objectives in that intent works on a timeline. We use the 5V Model to articulate the evolution of intent over a timeline. E.g., we want to achieve "X". To get there, we want to achieve "Y" by 2020 and "Z" by 2025, etc. We can execute our objectives at the same time, as with the given example of losing weight.

Objectives must turn into plans, otherwise they are just ideas. To create these plans, we turn every objective into a program. In turn, to execute a program, we turn its activities into projects. There is no difference between the construct of a program and a project. A program is a high-level work break down structure (WBS), where each action step becomes a project.

As Org executes its intent, a process construct will assimilate the project construct. I.e., The project construct will disintegrate.

Data beyond project flow

Project flow is not enough to create a project construct. Flow will name the needed activity, set priority, and give duration. To work, activity needs data and resources. People, money, and assets will give the energy whilst data gives the intelligence. Apart from flow, a programme or process will need the following data:

• A well-defined purpose.
• Defined objectives.
• A quantified effect.
• A risk assessment.
• Time boundaries.
• Weight and task classifications.
• Progress millstones.
• Clear links to processes, other projects, and programs.
• Etc.

One can add as much data to a programme or project as you need. Yet, it is good practice to view the given list as a core requirement.

"Detached" projects

In orgamatics, we promote the idea of "attached" projects. This means that Org aligns all its non-repetitive work to organisational intent. Such work will always take the form of a program or a project.

A key assumption is that the aim of non-repetitive work is to create change. With the orgamatics model, one must align all change initiatives to the intent of Org. We use vision to define such intent. Theoretically, this makes perfect sense. Yet, in practice there are several projects that one cannot link to intent. E.g., upgrading the parking lot, or arranging a farewell function.

To deal with this, Org must set a tolerance policy in terms of non-repetitive activity. E.g., if a tolerance level is 10%, then only one out of ten projects can be disconnected from the organisational vision. We call these "Detached Projects".

 Conclusion

There are a lot of things that must be in place before we design a project construct. Intent must be crafted. We use the orgtology 5V model for that. We must grasp the risks, opportunities, efficiency, and dynamics of Org. We use the orgtology DOEP analysis for that. Leaders must motivate the change. This means that they must create a more compelling future beyond current performance. The list goes on...

Vision is a decision to change. The project construct will guide us through this transformation. It will help us to move from one point to another through scientific method. In so, we reduce the inevitable risks that change will bring.