WHAT IS THE STRATEGY FOR THE EXECUTION OF YOUR PROJECT?

Once you understand the type of project and the way it will be staffed, you need to create a strategy for its execution. This strategy will bring together all the pieces of the complex jigsaw that you have worked on so far. If it is prepared effectively then the strategy will express clearly how the project is going to use the resources available to it to achieve the project goals. Since advanced projects normally have a large scale and scope it is necessary to write the strategy in a summary format. The summary should cover the resource needs and deployment for the four fundamental building blocks of projects:

• scope;

• quality;

• resource;

• timescale .

The strategy needs to cover each of these areas from two perspectives. Firstly, it needs to cover the short-term or the tactical work and, secondly, it needs to cover the long- term or the strategic work.

Scope

By this phase of the project the scope should be properly understood . The planning should be in place and a macro plan ought to have been published. This plan should explain what will happen and when it is going to happen. It is possible that at this stage some of the detailed descriptions for the work may still be incomplete. This is only likely to affect work planned to start more than six months in the future. This lack of planning for some of the work means that the strategy needs to cover both the known scope and the unknown scope.

Strategy for known scope

Many project managers find it odd that a strategy is required for scope that is understood. When the scope is understood it is likely that there will be a good understanding of the method that will be used to deliver it. This means that detailed plans can be produced, negating the need for strategy. For most project types this logic is probably true. However, advanced projects are not like other projects. The only certainty that you have in an advanced project is that everything is going to change. This is the nature of advanced projects. The work is normally new, it probably has not been tried before and it is often unknown whether it will be fit for its intended purpose. Often the sponsoring organization does not know what it is that it wants to achieve. It only knows a general direction in which it wants to go. For example, an organization may want to build a new headquarters. The organization may only know that it wants to make it an exciting space for its employees . It may have no idea what this really means but as the project progresses it may discover new ideas that it wants to include. As a result it may want to change direction.

This background of constant change is very important to recognize. The execution strategy is the method that you have for dealing with the constant change. It is this strategy that will ensure that the project will progress smoothly, quickly and easily. The strategy is the simple way of understanding where the project should have reached and at what time it should have reached it.

To build a great strategy you need to look at the overall project. Perhaps the simplest way of achieving this is to start with the macro plan that you have already put together. This plan already defines many of the meaningful points that are going to occur on the journey to the end of the project. These points are a great starting place for defining the known scope strategy. For the strategy to be successful it needs to avoid falling into the common trap of being too detailed. It needs to remain abstracted from the detail. This ensures that people reading the strategy, or following the strategy, are able to understand where they have reached at any particular moment. A good metric for the strategy is whether it can be written on to one or two sides of A4 or A3 paper. Generally speaking, if the strategy cannot be condensed into a small amount of space then it's too complicated. The strategy needs to be written in a manner that enables one person to understand all of it in one reading.

It can be tempting for a project manager simply to take the existing macro plan and rewrite parts of it from a new perspective. It is tempting to take the detailed milestone plan and simply write down the milestones and say ˜This is our strategy.' Whilst doing either of these things will speed up the production of the execution strategy they will not help you manage the project effectively. If you adopt either of these quick production methods then you should also accept that your execution strategy is worthless.

The strategy needs to be broad and high-level in its definition and its presentation. Perhaps a simple example of a strategy statement might be:

• In Q1 the foundation will be laid and all major ground works will be completed.

• In Q2 the framework will be erected, the cladding attached and the building made watertight.

• In Q3 the internal fit-out of the building will be completed and the power and services made available.

• In Q4 the building will be commissioned with all necessary equipment to allow it to work properly.

This short series of bullet points explains the complete strategy for getting a building constructed , fitted out and into operational use. Obviously there will be a large number of tasks that need to be executed successfully to achieve this work. These tasks will require a substantial amount of planning to enable the building to be built, the framework to be erected, the cladding to be put in place and so on. Designs would need to be agreed for the foundations, the steelwork, the mechanical systems, the electrical systems and so on. However, although all of these plans and designs are needed, they are not required for the strategy. The short paragraph with the four bullet points clearly explains to anyone the major stages of the building project.

As the project progresses you should continuously refer to this strategy. There is a clear objective for every quarter and a clear way of determining whether the objective for that quarter has been met. This makes it reasonably simple for you to determine if the project has remained on track and whether it is likely to achieve its overall objective. For example, perhaps at the end of Q1 the foundations have not been laid and the major ground works have not been completed. It would be reasonable for you to assume that the project is falling behind schedule. If the work still has not been completed by the end of Q2 then you would know that the project is in trouble.

Execution strategy is not only useful for assessing the current work. It also allows you to assess the future work. It sets out potential areas that should be examined for long-lead items that may need to be addressed early in the project. This enables you to anticipate work that needs to be undertaken early in order to achieve success. For example, the frame of the building may take many months to design and to get manufactured, especially if the frame of the building is unusual. You could anticipate this need from reviewing the strategy.

Strategy for the unknown scope

Once the strategy for the known scope has been defined you should centre your attention on the unknown scope. It is frequently believed that it will be difficult to define the strategy for the unknown scope. Since the scope is not clear, project managers often believe that a strategy cannot be created. However, defining the strategy for the unknown scope is not significantly different to defining the strategy for the known scope. The solution to understanding the unknown scope is to define what you don't know. Once you've defined what you don't know then it is possible to decide what needs to be done to define it. This can be simply achieved by completing a table that has different columns listing out the unknown scope, what's not understood about the scope and when it needs to be resolved. An example table is shown in Table 5.3.

Table 5.3: Unknown scope definition

Unknown scope description	Points to be clarified	Timescale for resolution	Comments
Size of code footprint	RAM available on device Architecture of device	RAM usage 3 weeks Architecture 1 week	Can make some basic assumptions that others will have to live with
UI design	What interactions are required	Prior to code work starting End of Q1	Basic UI can be created without the design, allowing work to progress

Table 5.3 shows four columns. The first column sets out the unknown scope for a particular item. The second column explains what needs to be clarified about the scope and the third column sets out the timescale that you have in which to resolve the points for clarification . Filling in a table like this will help you to focus on the unknown issues. Often you will find that there are only a few unknowns. Frequently the initial table will include a large number of items. However, an early review will quickly reduce the number included to a few key items of unknown scope. Once the key items have been identified they should be built into a strategy similar in manner to the one for the known scope. For example:

• In Q2 the operating system including its version needs to be defined and agreed.

• In Q3 the hardware needs to be selected and work on its integration needs to start.

You should now be in the position to write down two strategy expressions: one for the known scope and one for the unknown scope. Once this has been achieved you should be in a strong position to identify future scope issues. By being able to identify upcoming issues you should be able to reduce the risk on the project significantly. However, despite the benefit of this scope statement you must undertake other work before you can define the execution strategy of the project. A series of bullet points covering scope is not a project execution strategy. Clearly the other fundamental areas of the project need to be covered if the full strategic intent of the advanced project is to be conveyed.

Quality

Most project managers understand the need for quality and the need for a quality outcome from their project. However, many don't really understand the details of how quality is achieved. As a consequence of poor understanding, project managers are unable to guide and coach others in quality issues. This results in a general lack of understanding, which extends throughout the project. When this poor understanding exists, a clearly thought-through strategy for quality is unlikely to be in place. When this is the case you need to take immediate action. A well-thought-through quality strategy should be central to the project if a quality outcome is to be achieved. It is important that you take time to educate yourself sufficiently about quality to ensure that you are able to teach other people.

The first step in defining a clear quality strategy is to understand what is intended by quality. A common mistake in trying to understand quality is trying to define it in a broad manner, for example ˜We won't be satisfied until our customers are.' Whilst this is a great objective it is unlikely to help in the practical realization of quality. Sadly it is common for projects to take on such a statement as a way of introducing quality. You tell everyone in your team that once the customer is happy then you will be happy too. Unfortunately this way almost always fails. The customer rarely ends up happy. This approach is sometimes called the ˜general statement approach'. It is achieved by simply stating a general ethos for quality. Sadly most of these statements are too abstract for project team members . Examples of general statements are:

• ˜Quality comes at a price but it's a price worth paying.'

• ˜We will always strive to do our best - quality is important.'

• ˜Quality must be at the heart of our work.'

• ˜We measure our success by the quality of our product.'

Although these statements may inspire team members they don't actually tell them what they should do. Instead quality should be undertaken as a targeted activity. This means identifying specific tasks within the project that the organization is going to undertake. Targeting quality in this way, for a specific project task, ensures that it becomes measurable and useful to the people concerned . The easiest way to define quality for a project is to assess how you would measure whether the project has succeeded or failed. Effectively this is the definition of the mission statement of the project. Some examples might be:

• ˜End consumers are delighted with their new phone.'

• ˜The staff love their new working environment.'

• ˜The software never fails.'

• ˜Customers are breaking down our door trying to buy our product.'

These four examples are very different in nature. However, they do have a common theme and that is defining what a successful project outcome might be. Examining the project from the end user 's point of view, that is the customer's point of view, enables the quality criteria to be clearly and easily defined. However, these statements are not sufficient on their own to merit a quality strategy. They need to be broken down into manageable steps that allow implementation.

None of the example statements will be able to help an individual team member with the implementation of quality. Questions will be raised immediately such as ˜How can a simple strategy statement predict whether a consumer will be delighted?' Another question might be ˜How can you determine whether the staff loved your environment?' Put simply, a quality statement can't answer either of these questions directly. Instead the quality statement must try to assess the characteristics needed to resolve these questions. Once the characteristics are defined then the strategy can set out how to achieve the characteristics.

Defining the characteristics is achieved by looking for certain features. This is achieved by asking three simple questions. These questions aim to understand the fundamental issues with project quality. They are:

• Who are the judges of quality?

• How will they judge the quality?

• Is their judgement measurable?

The first two of these are reasonably easy to determine. For example, for the first quality statement it is the phone customers and their delight that count. The third question however, ˜Is their judgement measurable?', is a much harder question to address. You need to spend time assessing what customer delight is. It is possible to achieve this through techniques such as focus groups. Even if focus groups cannot be run it is still possible for you to gather trusted opinions to enable them to make an assessment.

You should spend some time with appropriate team members trying to answer each of the three questions. For each of the questions you should try to produce detailed answers. These answers should then relate to the original project quality statement. Wherever possible you and your supporting team should split the answers into chunks of time. Each chunk of time should have a measurable outcome associated with it. Once all the questions have been answered you need finally to set out a quality strategy. The strategy should be set out in a similar manner to that for scope. For example:

• In Q2 the key characteristics that will delight the customers will be defined.

• In Q3 the characteristics that will delight the customers will be checked by using a focus group .

• In Q4 the first sample product will be put to the focus group and remedial action taken depending on the feedback from the focus group.

• In Q1 the final product will be measured against the characteristics defined at the start of the project, that is the characteristics that you believe will delight the customers.

This completed statement can then be added to the scope statement. The next area to examine in producing the execution strategy is resource.

Resource

A well-designed resource strategy should enable you to achieve your goal. A badly defined resource strategy is likely to give significant problems. Often project managers controlling advanced projects don't bother defining a resource strategy. They mistakenly believe that the detailed work package plans will serve as protection against resource problems.

To get a sufficient overview of the resources needed, you need to revisit the macro plan. In the macro plan resources were examined from a summary level. They were broken into chunks and those chunks were defined on a time basis, perhaps quarterly. These figures should now be used and assessed against certain criteria. You should decide the criteria specific to your project. However, some useful guidance criteria are listed below:

• Are the macro plan estimates still correct when taking into account the detailed plans?

• Do the macro plan estimates explain what skill sets will be needed to deliver the plan?

• Is there training in place to make sure the plan will work? If there isn't training in place, is the training clearly identified?

• Are the resources available in-house or are they going to be sourced externally?

• Do the resource plans take into account the need of the scope strategy and the quality strategy?

With answers to these questions it's possible to start to pull together a resource strategy. As with the quality and scope strategies, the resource strategy should be succinct and time-bound. It is difficult to be prescriptive about the strategy statement since advanced projects vary so much in scope. However, it is possible to design a basic formula that can be changed, dependent on circumstances:

In quarter X resources will be required with the following skills:

• At least YY people will be required.

• A ZZ proportion of the work will be resourced using staff external to the organization.

Obviously the blanks should be replaced with actual figures. An example statement might be:

In Q1 resources will be required: general labourers, architects, clerk of works. At least 20 people will be needed: 15 labourers, 4 architects , 1 clerk of works. All labourers will be sourced from outside of the organization.

This resource statement should now be added to the scope statement and the quality statement. This should result in three chunks of strategy that all relate to one another.

Timescale

As with resource, a timescale strategy might seem an odd concept. Again it is easy to believe that the detailed plans will define the time line sufficiently. Whilst this is true to an extent it is only part of the overall picture. It is equally important to understand the main milestones in a simple fashion. This high-level picture helps to keep the project understandable. And indeed this time-bound method is already part of the three strategy statements that have been defined.

The first step in defining a timescale strategy is to gather together the main milestones. These are easily identified from the work packages. A simple list can prove to be effective and helpful here (see Table 5.4).

Table 5.4: Timescale strategy definition

Milestone	Work package	Due date	Comments
M1: Alpha delivered	Development of Application package 1	Week 4 (end of)	Functionality required is defined in project plan
M2: Beta delivered	Development of Application package 1	Week 25 (end of)	All functionality to be included although may not be debugged fully
M3: Release candidate	Development of Application package 1	Week 40 (end of)	Fully tested software

Table 5.4 has four columns. The first column is the milestone column and this should be populated with all of the main project milestones. The second column contains the title of the work package that the milestone is attached to. In some cases a milestone may be attached to several work packages; when this happens the prime work package should be chosen . The third column is the due date column and should be the planned date, not the planned date plus contingency. The final column is included to allow for comments to be added. The table should be populated with all of the major milestones within the project. Some project planning tools allow the creation of this table in an automated manner.

Once the table has been completed it is likely that there will be groups of milestones. If the list is constructed in a spreadsheet package it can be easily sorted. This makes finding the groups simple. The first column to sort by is the date. Once sorted by the date, the next step is to pick out some groupings. The simplest way is to start by dividing the total milestones in any one year by four. For example, 16 milestones in a 12-month period would be split into four groups of milestones with four milestones in each group. All milestone groups, once identified, should be examined to identify whether they are similar in nature. If they are then this should be used as a project group. If they are not then they should be moved between groups until a logical breakdown is achieved. The objective behind splitting the year into four is to enable you to build a quarterly statement. This type of statement is useful since it is easily remembered . Q1 is easier to remember than May to August.

You should now create a quarterly statement that covers the time line of the project. This should be similar to the previous strategy statements for scope, quality and resources. For example:

• In Q1 the project milestones M1 to M3 will be met.

• In Q2 the project milestones M4 to M9 will be met.

Once this statement is ready you are in a position to create the overall execution strategy for the project.

Creating the overall execution strategy

Creating the overall execution strategy is initially a relatively mechanistic process. You take the four separate strategy statements and combine them. This is simply achieved by using the cut-and-paste function on a word-processing package. You should resist the temptation to break apart the strategies or to rewrite them into one concise statement. Although this would make the strategy simpler to remember it would also reduce its impact. By not combining the statements you avoid any dilution of the intended message.

Once the mechanistic joining together of the strategies has been completed you must take time to build them into one presentable document. This means adding some basic explanatory text to expand bullet points that may not be obvious. The document should be no more than 2,000 words. Assuming there are 300 words on a page, this results in a strategy document that should be completed in seven pages including diagrams. Keeping the document short and succinct improves its readability and helps to ensure that busy senior managers will be able to find time to read it.

Once completed, the document should be presented initially to the project steering group and then to the key project stakeholders. The stakeholders should be gathered together and the contents of the document presented. The meeting should be followed by a question-and-answer session and finally the distribution of the project strategy document. The completed strategy should be updated and redistributed on a regular basis. If the strategy has been written using a quarterly timescale then updating on a quarterly basis would be a reasonable target. For shorter projects, months may have been used and therefore perhaps a monthly update would be sensible . In all cases you should use your judgement when deciding how often to update the strategy.