The Business Perspective
To the business, the activities involved in getting a project started can seem like excessive slow bureaucracy. Most tasks involved in the day-to-day running of an organisation can be started or ramped-up relatively simply. A line manager can re-assign a member of their team to a new task, adjust their regular schedule or request a bit of overtime. This means that an expectation exists that things will happen quickly and with minimum hassle. Projects do not follow this pattern, but business staff may not fully appreciate how different they are in terms of getting started. This can easily manifest itself in business impatience and early disillusionment: ‘Why haven’t we started yet?’
The role of the business within a project may not be evident to members of the business. They are likely to have a set of requirements, which, having engaged a project manager to deliver, they will then put on to the ‘back-burner’ in terms of their own priorities. But the project as it starts to come into existence will make demands upon the business that may be unexpected. The business participants find themselves asking the following questions:
‘Why do I have to come to all these extra meetings?’
‘What is this new project role I’ve just been lumbered with? I already have a day job’.
‘Where has this large crowd of people just come from?’
The business has got up a head of steam and is enthusiastic for the project to get underway and make visible progress. In fact, the sooner the deliverables can be given to the business, the better. From a business perspective, the tasks involved in setting up the project can appear to be very convoluted and nit-picky.
The key difference here is that the business already exists in terms of its structure, organisation and support functions. All the people are in place, they have job titles and roles, they know each other and they know what each other do. What they do is fairly predictable as it follows a regular pattern of activity – be it daily, weekly or monthly. Everyone is already equipped with office space and the technology they need to do their jobs, and they exist on the HR system and the payroll system. They have objectives and personal development plans. And, having worked together for a while, they function as a team – more or less.
Clearly the effectiveness of team working will vary between business teams, but the central point is that they have developed a collective modus operandi. If someone is away, it is quite likely that another team member can step into their shoes and cover for them, and the resulting work will be of reasonable quality. Everyone has already climbed their learning curve, which has happened gradually over a period of time. The function may have been in existence for many years, even if it is more recent; nonetheless, in all cases it will have evolved slowly. The tasks needed to set it up – staff onboarding, job roles, inductions, plans, team bonding, performance monitoring and tracking Key Performance Indicators – all of these will have been added into the mix by a process of accretion. This is where a project is fundamentally different. And this is why there can be a disconnect at this stage in a project’s lifecycle.
The Project Perspective
More often than not, projects start with nothing. They may make use of some in-house staff if there is a function in the organisation that does the type of project that is needed, but even this may not be the case.
A project that starts from scratch has to boot itself up whilst at the same time starting to get on with the activities related to providing deliverables to the business. Getting started covers a number of areas and involves answering and taking action related to a number of key questions:
What are we delivering?
How are we going to deliver it?
How much time have we got available to do this delivery?
Is what we are being asked to provide buildable – in principle and more specifically in the available time?
Who is going to do the delivery?
What environment, tools and infrastructure do we need?
How can we get hold of the people and equipment we need to do the job?
A fortunate project has time to find answers to these questions, take action and then get started on the main delivery. A project that is subject to tight time pressures may need to undertake the delivery tasks whilst still stumbling into existence.
Let us get back to these key questions for a moment. The justification activity that preceded the getting-started activity may have provided partial answers to some of these questions. This will vary depending upon how extensive and thorough the justification process was. If the project was subject to rigorous early analysis, then the answers will already exist and the task will simply be to put the identified actions into play. However, if the justification process was less extensive or simply consisted of a barked order of ‘Just get on with it’ emanating from somewhere on high, then the project manager will need to consider these points in detail before the project will have been established with a firm foundation.
What are we Delivering?
This may seem startlingly obvious to the business, particularly sponsors and people paying for the project. In fact, this is where the bane of unconfirmed assumptions can first come into play. What is needed is a clear specification of the deliverables, covering all the relevant categories, which can include physical objects (sometimes known as the core deliverables, e.g. a building, a road, a new product or a computer) but also all the other deliverables (which can range across documents, organisational changes – including the hiring or departure of people – the acquisition or disposal of companies and changes to the way in which an organisation works), new processes, training in those processes and general cultural change to ensure that the rest of the project is successful. This is where the assumptions trap comes into play for the first time, as the business and the project may well have quite different presumptions about what does or does not constitute a deliverable from the project. ‘What’s the point of a new system if we don’t have the staff trained and enthusiastically lined up to use it?’ might be the business viewpoint; to which the project could answer: ‘But you only asked for the system, there was nothing in the Terms of Reference relating to training the staff’. This is why a complete and unambiguous definition of what is to be delivered is required.
There are also nuances within this that need to be taken into account. One relates to what is not yet known. It is a classic in modern management speak that there are often aspects of a situation that are not known. These themselves can be divided down into those that people are aware that they do not yet know (e.g. we will have to get rid of people but do not yet know if it will be 20 or 200) and aspects that the people did not realise they did not know. A project is rarely in the lucky position to be able to get started knowing everything. Most of the time there are aspects of what is to be delivered – and how best to deliver it – that are uncertain when things are getting started. There is an interplay here with assumptions. The business may assume that the project realises that some aspects of the deliverables are uncertain, while similarly the project may assume that the business realises that some aspects of how the project is going to be delivered are not yet known. In both cases this may not be the case, and the unknown deliverables and the unknown project processes emerge later during the lifecycle as a nasty surprise for all concerned. Why a nasty surprise? Because by the time they emerge, the project has moved on to the extent that such surprises will disrupt the timeline and cost considerably more to change direction and incorporate these newly discovered aspects than would have been the case if they had been considered in the plan from the start. So to tackle this, the assumptions need to be brought out blinking into the daylight. The classic approach to this, which is perfectly adequate in the vast majority of cases, is via one or more joint workshops where the project and business come together, step back from the day-to-day tasks of the project set-up and via a facilitator highlight all the things that they assumed that the other party had already realised. Once identified, the assumptions should all be documented in a Register which can be made available across the project and the business so that all parties are aware of what is being assumed. In a few cases where there are two opposite assumptions (business assumes project is doing X, while project assumes it is not doing X and that X is the sole responsibility of the business), this may actually lead to the assumption being converted into a new part of the business-project agreement whereby a shared view is established on what is to be done by whom and the ambiguity and uncertainty is removed.
Another nuance relates to scope and boundaries. Even if there is clarity on what could be called the ‘central deliverables’, i.e. you are delivering a new system, there may be ambiguity in terms of what this includes on the edges. If the computer system has to work with other systems, then there may be a need for interfaces to be developed and provided. Different parties may make opposite assumptions about whether these fall within the scope of the project – traditionally the business will assume that they are included, as they would expect to get everything they need to make the system work, whereas the project would assume that unless they are explicitly stated as a deliverable, then they would not be automatically included as part of the project. Again, working through the assumptions, via workshops, and capturing these in a shared, documented and widely distributed Assumptions Register will help to reduce this potential problem.
One caveat about the Assumptions Register is that some parts of the organisation may be less used to working with uncertainties. Such individuals will, for perfectly understandable reasons, tend to treat the statements in the Assumptions Register as facts. If these later turn out to be invalid assumptions, with significant consequences for the project, then recriminations may ensue. To avoid this, the provisional nature of the statements in the Assumptions Register should be emphasised when it is distributed to a wider audience.
Firm Scope and Realistic Estimates
There is one other area which can lead to confusion in terms of what is going to be delivered. This can arise when the project is being undertaken by a team from a distinct and separate business from the client business. In this situation, the project may well have needed to be sold by the project provider to the business. This sales process tends to be done by sales specialists, who are expert in finding opportunities and clarifying customer requirements, responding to complex requests for proposals or invitations to tender, and can then navigate the tortuous process of ‘closing the deal’ and getting the customer to sign of the dotted line and contractually agree that the provider organisation will be the one that undertakes the project. These teams are very good at what they do, but quite often what they do does not include the details of laying the groundwork for the set-up of the project that has been sold. They tend to be distinct and separate from the delivery team, and, due to commitments to other projects, members of the new project team may have had very limited visibility of the sales process that has led to the award of the project.
To address this concern and risk, a proper handover is needed from any sales/bid/proposal team across to the project team. The scenario to avoid is one of ‘we won it, now you deliver it…’. This disconnect can lead to a very big risk if the sales team are so focused on winning the business that they do so at the expense of it actually being deliverable. This can be the start of the ‘over-promise and under-deliver’ nightmare. To avoid this fully, the project team needs to be involved in the sales process to an adequate extent to provide some ‘governance input’ around whether what is being proposed, as well as looking good, is something that can actually be delivered. This involvement needs to happen, in a light-touch way, all through the sales activity. Provided this has happened and a realistic project has been submitted and then won, the second step is to ensure a full and detailed handover from the sales team to the project team. This can best be illustrated by defining the opposite. The behaviour that most needs to be avoided is one of ‘throwing it over the wall’ with the sales team rapidly melting into the mist and disappearing the moment the project has been won, leaving the newly forming project delivery team to pick up the pieces before the project has even started. The much-preferred scenario is where the sales team provides a full set of documentation and a diary audit trail of how the sales process went, a stakeholder map of the client’s key players (including their expectations) and actually facilitates personal introductions of the project team to the business so that it is clear that a mature and complete internal handover from the sales team to the project team has occurred. There is no harm in doing this very visibly in front of the business, as this should give the business increased confidence that the aspirations they have shared with the sales part of the project delivery organisation have been passed across to the project delivery team, and that they are acknowledged, understood and will be reflected in the way in which the project is set up and run. In fact, the business should be concerned if it does not see evidence that this has happened; it may wish to actively push for a demonstrable handover to occur.
How are we Going to Deliver it?
This may seem obvious, but in practice considerable thought may be required in order to identify the right set of ‘ways of working’. The focus of this covers the methods and processes that the project is going to follow. These fall into a number of categories. Some are more abstract in that they relate to how a project is run irrespective of what the project is delivering, while others are specific to the type of project.
All projects need a list of what they are going to produce, a timeline or plan for what tasks are going to happen when, a way of dealing with changes, a way of making sure that the deliverables are of the right quality and a way of reporting progress and alerting senior management to problems. This can be provided by following a recognised method such as PRINCE2® (TSO for AXELOS 2009) or the approaches published by the Association for Project Management (APM 2013) or the Project Management Institute (PMI 2013).
Other aspects are much more specific to the type of project. Building a bridge, implementing a computer system, re-organising a department – all of these can be done using a project. The tasks that need to be done will differ greatly in terms of what needs to be performed in order to create a physical structure or an electronic artefact or a differently structured team of people.
This is where a project, when it starts up, needs to determine how it will go about creating its deliverables. Some projects may have ready access to a set of processes and methods, as they are housed in a function, or delivered by an organisation that specialises in projects and therefore has an ‘off-the-shelf’ method that can be adjusted to suit the needs of the particular project. Other projects, which exist with less of a support structure, will first need to invest time and effort in determining what are the right methods and processes for them to follow. This can be tricky to explain to the business as it appears that no actual ‘real work’ is being done, but without this first step, the project will get off to a very uncertain start and will proceed in a haphazard fashion.
How Much Time Have we got Available to do This Delivery?
This may or may not be at the discretion of the project itself. In some cases the business in dialogue with the project will ask the project for an estimate of how long the project is expected to take. Where this happens, the project needs to develop a detailed enough plan to be able to identify all the substantial tasks involved, how they all fit together in sequence, whether some can be done at the same time and, when they are all put together into a single plan, how long the overall project will take.
The project itself may vary in the degree of confidence it has in its own estimate. If many similar tasks have been undertaken before, ideally by the same team, then their knowledge of how long it took to do the previous projects, and their individual tasks, can inform an evidence-based estimate for this project. However, if the project is novel, uses new techniques or uses staff who are not particularly experienced in their planned roles, then the resulting estimated duration is less likely to match the eventual out-turn.
The project can make a trade-off here with regard to how much detail it includes in the plan. The greater the level of detail, the better the chances that the estimate will be realistic. This is because more tasks will have been identified and the time for each task will have been considered separately. A higher-level sketchier plan is more likely to include assumptions that may turn out not to be warranted and thus trip up the project, resulting in a different duration from that expected.
Is What we are Being Asked to Provide Buildable?
This is a key question that the project will want to ask before getting started. The business will presume that the requested project is achievable. A good project will include a degree of scepticism and will challenge this assumption. It is better to uncover potential problems and pitfalls earlier rather than when the project is well advanced. This is not for reasons of pessimism, but actually to give confidence that the plan is well-founded and that the project can safely move forward.
It is worth noting that having determined that a project is buildable, there is a different question that should also be asked, which is whether the project is worth building. This will be considered later in this book in Chapter 16.
The handover issue mentioned earlier can also affect whether a set of deliverables are buildable. This particular challenge can come when the project has been designed, sold and won by one team (the sales team) and then passed on to a separate team to undertake the project (the delivery team). The members of the project team may suddenly find themselves with a set of delivery obligations which they did not have any part in creating or agreeing to. In the worst-case scenario, they can feel ‘stitched up’, with an obligation to provide something that, although it appeared fine when it was being sold, turns out to be much harder to build than the sales team expected. This can prompt and justify a legitimate scrutiny of what has just landed on the doormat in order to make sure that what the project team is about to take on can actually be done.
There is also a secondary question that a good project will ask. Having determined that what is being requested can be built, it then needs to check if it can be built in the available time. The project may have a timeframe and deadline that are outside the control of the project team. Although the required deliverables could be created, their complexities, interdependencies, the supply chain, the necessary raw materials, the skills required from the team and the resources needed simply may not be available in suitable quantities or quickly enough to enable the deliverables to be achieved in the available time.
Again, although this may appear negative, it is actually a very important part of the project’s due diligence. By determining this upfront and alerting the business to this problem right from the start, a negotiation process can be entered into to resolve the problem. It might be possible to deliver half the project, to provide all the deliverables, but to only half the planned locations, to renegotiate the timeline and extend the project or to remove a resource constraint by increasing the budget. It is better that this surfaces earlier, because the longer a project waits to share this type of bad news with the business, the nastier the surprise will be for everyone, the less remaining time there will be to find a remedy and the more it will cost to resolve.
Who is Going to do the Delivery?
This question may seem obvious, but the project will need to design its organisation structure based on the tasks that it has to perform in order to create the deliverables it is being asked to provide. Default roles may exist, such as Project Manager, Assurance Manager, Project Office Manager, Designer, Developer and Tester, but these then need to be brought together into an organisational framework that is specific to this project.
The quantities of resource also need to be determined. There may be only one Project Manager, but how many designers and testers are required? Also, ‘When are they needed?’, since not all activities will start at once or last for the full duration of the project. The team needs to be planned fully, including its growth and shrinkage over time as the project progresses. At the end of this activity, there will not yet be an active project, simply a degree of clarity on what roles are needed, how many, when from and for how long. This is the start of the project’s HR plan of action.
What Environment, Tools and Infrastructure do we Need?
Other logistical elements can also affect how quickly the team can come up to speed. A project is an organisation in itself, there may be a need to provide a range of equipment (suitably configured laptops), office space, shared storage for online documents, security clearances for team members or the field next to the road being widened to hold the site office. None of these is difficult in itself, but there tend to be assumptions that they can be provided instantly and in quite large volumes by the host organisation. This is rarely the case, so often new project team members are faced with a poorly organised start and induction (sometimes known in the jargon as onboarding) into the team.
The project as a ‘mini-organisation’ also has to sort out various other aspects of its own housekeeping. This will include activities such as project finances, timesheets, expenditure tracking and matching against client payments. There may be a suite of systems and tools (very often complex spreadsheets) that enable this, but even so, this all needs to be put in place and kicked off. Similarly, HR arrangements for the team members need to be established and steps taken to build a shared vision and team spirit for the project.
How can we get Hold of the People and Equipment we Need to do the Job?
This is all about ramping up the team. Having a ‘standing army’ costs a lot, so most organisations will not have a spare set of project resources in place that can all start working on day one. It can take time to find them, particularly the right people. In fact there is a natural limit to the rate at which new team members can be onboarded. Too many joining at the same time will divert the flow of the project from making progress into simply assimilating all the new staff onto the team. A project needs an esprit de corps and this is often best fostered by growing the team incrementally. Too many staff arriving at the same time can lead to confusion and lack of direction, as well as overstretch for the existing team members who need to devote effort to inducting the new members.
However, once in place, a ‘marching army’ also costs money. Project staff need to be productive and it is not good to have them waiting around to get started. A team of designers who cannot get started producing the detailed design because the requirements have not yet been agreed with the business will cause problems. To keep them busy, a design may be put together but based on a large number of assumptions, and it will need extensive rework once the requirements have been finalised. In addition, delays such as this can impact morale and set a bad tone early in the project.
Bridging the Divide
This may all feel excessive to the business, but what is key to understand is that without a firm foundation, the project will simply be a house built on sand. It is important to get the details correct right at the start. Something small that is neglected or done badly in the set-up, although seeming minor, can have an effect that is multiplied considerably downstream and will potentially have a much greater negative impact on the project than might be expected. An Internet search for the proverb ‘For Want of a Nail’ will give a feel for the sort of consequences that can arise from a small item being overlooked at the start of an endeavour.
So how do we attempt to bridge this gap at the project start-up? Remember, this is key because an early disconnect can itself grow into mutual incomprehension and deep mistrust if a strong business-project link is not established. What do we need to consider and take action about?
This involves bringing the project personnel and the business staff who are on the edge of the project together into a single unified team. At a tactical level, fusing them into one team means they should be united and concentrate on tackling external challenges rather than splitting into two camps that do not know or understand each other and thus focus their efforts on blaming and fighting each other.
The classic concept of Tuckman team stages (Tuckman 1965) will naturally apply to this activity. The concepts relating to these stages of evolution of team performance going through Forming, Storming, Norming, Performing and Mourning are generally well established within both the business and project worlds. The critical point to take on board here is that because the team will grow incrementally, it will go through multiple parallel strands of these stages. An assumption by the early joiners that the first few stages have been achieved and performing reached will turn out to be undermined if additional new joiners are not actively engaged into the team.
The benefits to the project of including members of the business in a unified team will be lost if a number of hygiene factors are not addressed. It is important to properly sort out the secondment of the business team members so that they have clarity about what is expected of them, which may differ significantly from their day jobs. They are likely to be included in the project for their business knowledge, but not necessarily for the operational skills they use on a day-to-day basis. They will need inducting into the project and to receive training on how to be effective project team members. Care must also be taken with backfilling the roles of the seconded staff. This is central to ensuring that the business team members are not overloaded from their old day job, with a leakage of time, effort, energy and focus back to the business. This leakage can take a number of forms – one is where, whilst they are on the project as the ‘resident expert’ in their area, their time and knowledge is repeated requested by the business because they are best placed to resolve tricky day-to-day problems faced by the business. The other form of leakage is simply related to not having someone to take over the day job, which means that the business team member ends up doing two jobs – the new one on the project and the old day-to-day one. Finding backfill resources can take time and projects tend to march off into the distance regardless of the degree to which the business resources are available and ready to help.
Business Team Training
One area of risk to project success is unwarranted assumptions. A classic example of this is assuming that all members of the business team are familiar with and understand the way that projects work. It is well worth checking whether this is actually the case. Of course, levels of project familiarity may vary. In particular, senior management and junior team members may be less project aware than middle management, who could well have participated in projects before. Sensitivity is needed here so as not to be perceived as being patronising to business team members who do understand projects. An appropriate sounding-out of the key players in order to get an understanding of how familiar team members are is a good first step. On the basis of this, the project team may well need to brief and, if necessary, train some the business members in the lifecycle and techniques being used by the project. As part of this induction, it is well worth explaining why the various types of paperwork and apparent bureaucracy are needed, what benefit they bring, the risks of ignoring or skimping on them, and the active role that the business team needs to play. When one is familiar with a particular activity or process, the documentation involved in it can seem both reasonable and necessary; when one is unfamiliar, the same level of documentation can seem daunting and excessive. There is no ‘one-size-fits-all’ approach to this, and the same consideration about new joiners arriving during the ramp-up of the project applies again as it did earlier. This means that the induction material can usefully be codified into a set of briefing notes and training material that can be repeatedly delivered as and when new business team members arrive.
At the same time as getting the business team up to speed with the working concepts and methods of the project, it is also valuable to focus on the project team. In this case the aim is to make a point of inducting the project team members into the business team’s world. The project team may not be particularly familiar with the business. This could encompass the core business of the organisation, how it is structured, how performance is measured and what the working pattern and calendar is for the business. All of these unwritten norms provide a context that the business team will be familiar with, but one that can trip up the project team members. Time spent on such an induction can be more than paid back as the project team members will then appreciate the subtleties of the way in which the business works and will finesse their approach to make sure that the project runs smoothly within the context provided by the business.
Whilst considering induction, it is worth noting that there may be ‘business as usual’ processes that support some of the onboarding and housekeeping functions; however, because the project team may all be new, they may not be aware of them. Project induction should therefore start with the Project Manager and should include an introduction to the support systems – human, logistical and technological – provided by the host organisation.
Induction activities should be repeated regularly as the teams grow. Do not just focus on the first few joiners and then expect everyone else to pick things up by osmosis – deliberately make sure that all those joining the project and shadow business teams get a full induction.
Projects run to a pattern of activities that is separate from the main business. The phased nature of project activities can feel alien to someone who is used to a regular routine of work pattern. However, the control mechanisms of a project do tend to run to a calendar of some sort. This is when the heartbeat of the project is established. They consist of the obvious (to the project team) regularly monthly and weekly meetings and reporting cycles. An indication of the intensity and pace of the project is often the frequency of such meetings. A project that is running to schedule and not facing too many challenges may choose to operate monthly senior management meetings and weekly team meetings and reporting. If things are not going well, even from the start, then the frequency can be adjusted to weekly senior level meetings and daily progress meetings. These often happen at the start of a day and can be known in some organisations as ‘morning prayers’. The advent of ubiquitous conference-call technology can mean that once a team has gelled with face-to-face meetings for the first few days, these often turn into teleconferences. However the heartbeat is established, what matters is to get business members of the team involved from the start.
The effective use of agreements can provide a very good mechanism to achieve bridge building. The nature of the project–business relationship will drive the type of agreements that are developed. If the project is being provided by a totally separate organisation, then inevitably there will be a legal contract between the project’s organisation and the business organisation. The trick here is to cover all eventualities from a legal perspective, which trained lawyers are expert at doing, but in a way that enables flexibility to be achieved. The essence of a contract is that it should provide clarity about what is to be delivered, how success will be judged and how one party will pay the other party. However, it is written from a pessimistic frame of mind and includes many sections that cover all the different eventualities that might go wrong. This means that ‘all the bases are covered’, but, as a result, the contract tends to be long, sometimes obscure and inaccessible, and generally has a negative tone. In essence, it should only be needed if something bad happens. The positive aspects, i.e. what is to be delivered, should be at the ‘front and centre’ of everyone’s minds so that reference to the contract to check what is to be delivered should not be necessary.
As a result, one way of looking at a contract is to contrast an effective project with a troubled one. A healthy project puts the contract away in the drawer on day one, merges into one team and just gets on with it, in a spirit of cooperation, joint working and shared success. A toxic project keeps thick bound copies of the contract on the desk, refers to it every day and uses it as a brick with which to beat the other party into submission.
It is also worth noting that this contractual situation can repeat itself a number of times if the project organisation itself has suppliers who are separate organisations. Then the project needs to make sure that any obligations it takes on are flowed down to its suppliers using back-to-back contracts, which means that the supplier to the project team has the equivalent obligations and responsibilities as the project team to the business. Setting up this supply chain of contracts can take time and can delay the effective start-up of the project, particularly if there are a number of suppliers or a long chain of sub-suppliers.
Having covered the situation where there are two or more separate legal entities involved, we can now cover the other situation where both the business and the project team reside within the same organisation. Oddly enough, although one might think that this would be simpler, there is in fact greater scope for ambiguity. The reason for this is that since both the project and the business reside in the same organisation, the nature of the relationship between them is actually more informal. It is certainly unlikely to be documented in a formal contract. There may be some sort of Terms of Reference or internal Memorandum of Understanding, but in general there will not be a formal document that describes the obligations that each party has towards the other. As a result, although there may be an enumeration of what is to be delivered, the other areas that a contract addresses will not be covered in any particular document. There will be silence and presumption around the ways in which the two teams interact.
This means that instead there will need to be a fairly detailed document that gets the project started. The classic example is the Project Initiation Document (PID) (Managing Successful Projects with PRINCE2™ 2009: 254). Whatever the title of document is, the main point is that as well as describing the deliverables and scope of supply, it also needs to address the processes and methods that the two teams (the business and the project) will use for working together. It should cover the different roles that exist in each party, what they are responsible for and in particular how they interact. It will also need to cover the governance structure – the committees and meetings which happen on a regular basis – that control how the business and project work together to steer the project forwards.
Avoiding Historic Enmities
An extra challenge in this situation may arise if the project and the business teams have worked together before on other projects that have not gone well. There may, as a result, be deep-seated misgivings, animosities and distrust that sit below the surface of the day-to-day conversations involved in setting up this new project. Care will need to be taken if there is such a history, as two aspects need consideration. The first relates to being clear on what went wrong on the earlier project and taking deliberate and visible action to make sure that such mistakes are not repeated. A lessons learnt workshop would be valuable. Even if one was held for the previous project, a follow-up workshop with a focus on ‘How will we apply the lessons learnt from the previous project’ will be valuable. The second aspect relates to the softer interpersonal issues, active steps will need to be taken to acknowledge any simmering tensions or resentments due to the earlier project and to take steps to defuse these. A project where one or both parties starts up with a view of ‘I don’t want to work that bunch of …’ is doomed to run into some sort of trouble sooner rather than later. This is where social activities which bring the two teams together away from the work environment can help, but a single event is unlikely to be enough. Barriers of mistrust take time to break down. Sometimes an artificial training environment, which puts the members of both parties together into a single team, to tackle some sort of challenge – maybe of a sporting or adventure nature – can help. The key here is that both parties need to become a single team, and this can be achieved by uniting them to face a common challenge and putting them in a situation where they have to rely on each other, and in doing so discover that the other party is not so bad after all. The exact activity is less important than achieving the objective of unifying the two parties into a single team so that they have more recent shared positive experiences of working together successfully that will ‘over-write’ in their memories the pain of the previous unsuccessful project.
Start-up provides the point at which Stakeholder Management needs to be developed and put into effect. This will involve analysing and classifying all of the different stakeholder groups and assigning them to appropriate categories, usually on the basis of their degree of interest and degree of influence or power (Slack et al. 2012). This has three benefits:
it makes sure that all parts of the wider business are identified and taken into account;
it enables the communications with each of these groups to be developed and tailored to their level of knowledge and interest in the project; and
it provides a mechanism for prioritisation of stakeholder management activities so that a limited budget of time and effort can be deployed to the best effect.
So as not to antagonise stakeholder groups, especially if they stumble upon a stakeholder map in which they feature and about which they know nothing, it is best to be open about the stakeholder management activity. To do this, it can be very helpful if the project team enlists the help, knowledge and insights of the business team.
This is also the point in time to recheck and reconfirm the alignment of the project timeline and the business’ regular cycles. It is important to identify and take into consideration any potential clashes between the project timeline, particularly major events like approvals of key documents, involvement of the business in testing and acceptance, and actual ‘go live’ activities, and the Business as Usual calendars of regular meetings, month-end processing deadlines and predictable seasonal busy periods. This can uncover potential considerations such as ‘We can’t decide this now’, ‘We can’t confirm that until then…’, ‘We can’t change this on that date’ and ‘We can only go live in those two weeks, not at any other time…’. It is far better to identify these now and make the necessary amendments to the proposed project schedule than it would be to discover these later and then attempt either to ram in the project regardless or to have to make emergency re-plans to take account of these events that were foreseeable but were not identified early enough.
Bringing the individual teams together is not as obvious as it might seem. If too many new joiners all start at the same time, then there will not be enough bandwidth to concentrate on the project. In addition, there will not be enough informed team members to provide a comprehensive and coherent introduction to the project. This may well come as a surprise to the business. Therefore, it is best to agree a way to balance everyone’s strong ambition to make progress against having a realistic view on the achievable ramp-up rate for staff to join the project team.
Geography also needs to be taken into account. A project where the client business team and the project team are all in the same office is simple and straightforward. However, except perhaps for in-house IT departments, this is rarely the case these days. The split can come in one of two ways. First is a business-project split, where the business and project teams are located separately. If this is on different floors in the same building, then this is relatively trivial, but any greater degree of separation is enough to make it necessary to engage in an active effort to prevent a ‘them-and-us’ mentality developing by accident. Nearby buildings will still allow for regular face-to-face interchanges between the people in the teams. This should be encouraged. Although email provides an audit trail of potential agreements, at the same time it removes many of the nuances of effective communication and should be used appropriately and not just as a blanket default communication mechanism. Any greater geographical separation between the project and the business – different cities and particularly different countries (potentially exacerbated by different time zones) – should be actively countered. This can be done by deliberately choosing to hold a number of initial face-to-face meetings in the same room in order to create esprit de corps. Only once these relationships have been strongly established should the project and business fall back onto video and audio conferencing. The use of email only should be avoiding wherever possible as this will inevitably lead to potential misunderstandings.
We also need to consider the individual teams, particularly the project team, but also maybe the business team if this is being formed especially for the project. If the team needs to be geographically spread itself, then there is an approach that may help. Spreading a team that has previously worked together in one location around the across multiple locations will be more efficient than having separate teams who have not worked together before. This means that if it is possible to construct the team using a number of people who have worked together before in the same location, then a set of norms and effective operating practices will already exist. These are more likely to be maintained when this set of individuals is then spread around a number of locations when compared to a situation in which people who have not worked together before have to build working relationships from scratch whilst being at opposite ends of a telephone line or email exchange.
There are further considerations when the project team is itself not from a single organisation. If multiple suppliers are coming together into a consortium, it can take time for them to find an effective way to work together. This is analogous to the situation described earlier where the project and business teams need to be welded together into a single team. Here, even within the project team, there are multiple viewpoints, experiences and assumptions that all need to be addressed so that a unified delivery consortium can be effective. Each member may also have had to handle the challenges of a sales handover of variable quality from their respective sales teams, which means that they may not all be starting from the same level of understanding. The fact that a consortium is likely to have a lead organisation and then a potentially complex web of suppliers and supply chain partners injects an additional commercial tension into the project team, which can make ‘ego-less’ partnering more difficult. All of this bringing together of a consortium to form a project team takes time, especially since they will almost inevitably be geographically separated. International consortia pose even greater co-ordination challenges. The business may not appreciate (or care) about this and will not always have allowed time to do this; nonetheless, such a view from the business does not mean that this activity can be skipped. As such, the project needs to work with the business and educate it about the realities of what will be involved before a large consortium is really in a position to deliver to the business.
A further complex scenario arises when the business client is, in practice, a collection, federation or combination of a number of separate organisations. This can quite often happen with clients in the public sector, where one central body procures a project to be delivered to a number of local organisations, maybe one in each geographical region in a country. Sometimes these local organisations are divisions of the main central organisation, in which case the central body has some authority over them, particularly in terms of achieving agreement to requirements. But in other more complex cases, these local bodies can have considerable autonomy. Where this happens, the central client may have to use powers of advocacy, persuasion or manufactured peer pressure (e.g. publishing a league table of relative performance comparing the local organisations against each other) to reach a situation where all of the local bodies actually agree to what the project is going to deliver. The extent of focus that is then required on stakeholder management can grow quite substantially. There will also be a need to establish ground rules about who does the stakeholder management across the federated client. In some cases the business may delegate this to the project team because it views it as an inconvenient chore, while in other situations the relationship between the central client and the local organisations is highly political and sensitive, so that the central client will not want the project team stepping on its toes and messing up the internal politics. This may suit the central client, but the time needed to work through the internal bargaining on the client side may prove excessive from a project perspective and may slow the rate of progress against what was initially planned and hoped for. In all such situations, the risk of incorrect assumptions again comes into play, as both the project and the business may have assumed one approach to stakeholder management when in fact the other approach was assumed by the other party and either not enough stakeholder management happens or alternatively overkill arises and the stakeholders are bombarded with inconsistent messages from all sides in an unscheduled fashion. Thus, to bridge this potential gap, the core management of the business and the project need to discuss this possibility early and in detail so that sensible agreements can be reached on how this will be approached.
The final and most complex scenario arises when both the delivering project team is formed from a consortium and also the business client is a combination of a number of separate organisations. All of the foregoing considerations above apply, but due to the additional complexity introduced by having consortiums on both sides, additional time will need to be included for establishing agreements, operating effective lines of communication and running decision making mechanisms that balance consulting all of the parties with still making timely forward progress.
One extra complication is that nothing stands still for long. In particular with large teams from potentially a number of organisations, it is quite likely that sooner rather than later there will be a change in one or more of the key personnel. Whenever this happens, some of the activities undertaken to establish the teams and their effective working patterns will need to be repeated. In particular, it is important to re-establish face-to-face working relationships and not to assume that previous ones will automatically carry over and carry on.
The project will operate in a context and support environment that can either enhance and empower it or distract and detract from its ability to deliver. This support environment can be provided by the business itself, particularly if the project team and the business are part of the same organisation. Alternatively, if the project team is coming from an external provider, then it will need to support the project team with a certain amount of ‘housekeeping’ in terms of staff induction, equipment, time tracking and financial systems. Even in this latter situation, it is quite common for a supplier’s project team to be based at the client business’s premises, which means that the client business will also be involved in making sure that the project team has everything it needs – desks, access to computer systems, the ability to record time and expenses if appropriate, and the ability to schedule meetings and arrange transport. Although apparently run-of-the-mill and administrative in nature, if these areas are not addressed adequately, the project team will find itself frustrated and will not able to get started effectively.
Well-aligned top-level governance structures for an organisation can assist or hinder a project. This applies to the organisation that is providing the project team, but even more so to the business. If there are boards and senior directors (e.g. Chief Operating Officers or Vice Presidents) with responsibility for programme and project management, then an organisation is much more likely to be successful in supporting the project. Where there is a structure that is more traditional and silo-based and does not include any provision for projects, it will inevitably be less well aware, aligned and supportive at a top level of projects in general and the individual project in particular. This can only be a bad thing and will not help the project get established, be well understood or its challenges and achievements fully appreciated.
To the business, the activities involved in getting a project started can seem like excessive slow bureaucracy.
The role of the business within a project may not be evident to members of the business.
The business already exists in terms of its structure, organisation and support functions, which is different from a project that usually has to set itself up from scratch.
When it is starting up, a project has two strands of activity: the early deliverables of the project – mandates, requirements and plans – together with the work involved in setting itself up with staff, facilities and its own working practices.
– what are we delivering?
– what is the scope?
– are the estimates realistic?
– how are we going to deliver the project?
– how much time is available?
– is this buildable?
– who is going to do what?
– what environment, tools and infrastructure does the project need?
– how can we get hold of the people and equipment we need to do the job?
– understand the importance of attending to small details at the start;
– establish combined joint teams, fusing the business personnel and the project staff into one team so that they become united and concentrate on tackling shared external challenges;
– appreciate that as new people join both the business and project part of the teams, that the team’s effectiveness will dip and that repeated cycles of effort will be needed to re-establish a cohesive team that can perform effectively;
– handle the impact on the business of using members of the business on the project – both in terms of disruption to the regular flow of the business and also the extra stress on the business staff who are working in an unfamiliar project style and may still have the old day job making demands upon them;
– introduce members of the business team to the way that the project works;
– introduce members of the project team to the way that the business works;
– projects run to a pattern of activities that is separate from the main business. The phased nature of project activities can feel alien to someone who is used to a regular routine of work pattern. What matters is to get business members of the team introduced to this and involved from the start;
– invest time and effort in getting agreements, especially contracts, settled as soon as possible;
– make deliberate efforts to build effective teams, taking into account the effects of geographical separation;
– be aware that complex supply chains and members of a consortium can take time to gel together into a single team;
– be cognisant of previous bad experiences that the parties may have had working together and take steps to ‘over-write’ these by holding combined activities to break down barriers and establish a bond of renewed trust;
– identify stakeholders and work together to actively manage them;
– recheck and reconfirm the alignment of the project timeline and the business’s regular cycles;
– establish a strong support environment for the project team – in terms of technology and business functions such as HR, technology, procurement, legal and facilities management;
– make sure top-level governance structures are optimised to help rather than hinder the effective conduct of the project;
– have plans in place to repeat some of these activities whenever new people take up key roles in the business or project.