A workable approach

The methodology that is applied to the particular project has to be executable by the workforce of the project. The best methodology with the best workforce can still result in a disaster if the two were incompatible.

​

The correct structure of the project and the approach

The way that projects and sub-projects are structured in terms of architecture, scope,
content and context of what a project addresses, implies that there could be result
dependencies between projects. If this is not done absolutely correctly it could easily kill a
Business Engineering initiative.

​

The correct people in terms of:

• Technology aptitude

• Leadership

• Approach that is applied

• What often happens in South Africa is that people leave their jobs from retail, production  or other environments and joins consulting houses to be deployed as Business Engineering consultants at exuberant rates the following day.​

​

Clear Strategic Positioning as a first step

This enables verification of all deliverables in terms of whether they support the vision, future direction and mission. A lack of doing this would result in a project implementing business changes in a ‘Vision vacuum’.

Without this one would be building solutions without any context to where the business should be heading.

​

Cut the cord of the existing business according to a rigid timeline

It is human nature to delay the instantiation of new solutions. One has to force the instantiation deliberately to ensure the switch over from old to new.

​

Visible executive and senior management commitment and support. They must bee seen to take the pain

It is amazing how much emotional support and co-operation it generates when a CEO visibly supports, and is seen to participate in a change initiative of this nature.

​

The business' and project team's mutual understanding of the project in terms of:

• Approach

• Scope

• Deliverables

• Implications

• Constraints

​

Often the business community expects the project to address a much larger or much smaller component of the business than what it actually does.

The methodology and its implications are not always well understood by the business. What can it deliver and what will it definitely not deliver.

The intended deliverable of the project can often be misunderstood. The business expects a lot more radical change until the deliverable gets close to completion, they almost suddenly want less then, etc.

Often the rumours start flying that an entire management layer will be stripped from the organisation as a result from a project, even during the phase where the project is only being scoped. One needs to state the implications that the result will have on the business as soon as clarity is achieved on these.

The CEO normally responds to a quote of a million Rand and six months to completion from Business Engineering team by asking, ‘What can you do for me for two hundred thousand in three months?’ One can deliver a lot, but something different.
 

All projects can be executed within constraints provided that the business and the project team have a mutual understanding of the implications of the constraints.

 

Empowerment of the Business Engineering team

The example under point number eleven is also a classical example that illustrates this point.

​

Must be able to measure the benefits of the results

A Business Engineering initiative should actually fund itself relative to the positioning in a new external – and target environment as well as the benefit derived from deploying a new business.

​

A compelling business case

From a business point of view this is absolutely not a valid business case.

​

The political will to change

The following article is an example of just how relevant this could be. The opinions expressed in the attached article do not represent those of the writer but merely serves as an example of the above.

​

​