We have a long-standing relationship with the APM dating back to the 1990’s. More recently CITI has become the biggest supplier of APM accredited courses after being awarded two major UK Government contracts: one to deliver all the PM training for UK central and local government, the other for CITI to be 1 of 10 preferred suppliers for the UK Government to provide PM consultancy!
http://www.citi.co.uk/citi-chosen-as-preferred-supplier-for-uk-government-ppm/

http://www.citi.co.uk/citi-appointed-supplier-on-new-consultancyone-government-procurement-framework/

This makes CITI the largest provider of APM-accredited courses in the UK and combined with the ‘beyond method’ workshops we and they provide, have more people attending project management courses than any other provider.

If you have any questions please call 01908 283600 – or to see future events please go to:
http://www.citi.co.uk/category/news/events/

The following documents were discussed and handed out during the event, they are available below electronically:
Make it happen
Making learning work
Matching learning styles
Experiential learning choices

If you would like to complete the 70-20-10 questionnaire, please visit http://cslive.citi.uk

We challenge project managers to think more broadly about the skills and approach they need to be truly effective in the role.

Process plays a crucial role in improving safe governance of projects. However, it should not become the project manager’s ‘comfort zone’.

Let us take the example of managing conflict in projects.

Project managers sometimes choose to avoid conflict in projects. They may recognise disagreement over the problem being addressed, the objective or the benefits of a project. However, sometimes project managers may feel these conflicts are intractable, or beyond their capability to resolve, or just ‘too much hard work’.

When this happens, project managers try to compensate for a lack of stakeholder agreement with process, producing a comforting array of technical documentation and gateway sign-offs. However business requirements documents, architecture designs and other project paperwork will not solve an essentially ‘political’ problem: if left unresolved it will eventually resurface as a bigger problem later.

In these circumstances what would be a better approach?

Working with the sponsor to reach the resolution of the underlying conflict? Ensuring that the project can move forward on firmer foundations? Securing senior management support for the project mission?

This requires the project manager to get out of their comfort zone and take a more business outcome focused approach. She or he must approach the project ‘from the outside in’ – talking to the business about strategic outcomes and business issues first, rather than solely concentrating on technical delivery.

How can you, the project manager, gain such insights and skills?

At CITI we advocate that you take up opportunities to project experience a variety of business environments.

This does not necessarily mean that you should ‘job-hop’ from company to company (there are great advantages in building up a supportive network of stakeholder allies over time) but it certainly means refusing to be type-cast as an ‘expert’ in a single technical field. You should not pursue greater depth of technical knowledge (and be aware that this is a tempting comfort zone). Instead you should seek to develop your understanding of business issues, perspectives and language.

If you experience a variety of business project challenges, and learn not to rely on deep technical knowledge, then you will be able to engage your stakeholders much faster engagement and communicate with the business more effectively.

That is why at CITI our assessment tools (used to recruit and develop project professionals) examine attitudes and experience as well as process skills and knowledge.

Dale’s sponsor had seen similar legislative-led changes first hand in the US, and she had a pretty good idea how tricky this might turn out to be. With several senior staff still thinking they could get away with applying ‘minimal changes’,he sponsor decided to instigate a research initiative. This was facilitated by Dale, and led by George, the Head of Equities.

Dale describes the choice of herself in this role as ‘interesting’. She was certainly not the expert in this area, and would need to rely heavily on George. Yet it was George and his team who were the most resistant to the change. She did have, however, an ace card – she had worked alongside the fund managers, a critical stakeholder group – and she knew them well. She had developed a relationship of mutual trust and respect – something not easy to gain in this environment.

The initial research focus was on what needed to change. What was necessary and acceptable was confusing, and this was giving individuals and companies the opportunity to drag their feet in implementing the changes. It was not until Dale and the team attended a presentation by the FSA (Financial Services Authority) that it became clear that the project would demand more than just cosmetic changes by UK-AMG. Following that meeting, “even if we didn’t like it and even if we didn’t know how to do it yet – we were all agreed on one thing, this was a big change”, commented Dale.

The FSA Consultation Paper impacted on core business practices and whilst it was not prescriptive, the group started to see that the implementation would affect how traders got paid, and would require changes to commercial trading relationships. These are all very sensitive matters: get the analysis wrong and the business could lose market share and access to its best Trading Houses.. Don’t implement it right; and the company would potentially face sanctions from the FSA and angry investors.

The initial research made it abundantly clear to Dale that “the impact upon systems, processes, clients and suppliers was huge; much greater than I think any of us had anticipated.” With the now very positive support from George, from her sponsor, and from the many other business stakeholders, Dale was ready to start the project. There was, however, one major group left to engage – IT. IT was essential in making this happen, but there was a long history of poor working relationship with the business!

“When I first went to see the CIO about the project he told me to raise a job request with the PMO”, Dale remembered wryly. “They just didn’t see the significance of the changes.” Though Dale had strong relationships with the business, she faced real challenges trying to persuade IT of the need to prioritise this work. She urgently needed access to a good business analyst as she suspected the best way to move forward was to get real evidence on just how big and how complex the changes would be – and in a language IT could understand. “So basically I had to be a pain – I just kept going upstairs to IT and making it clear I wasn’t going to go away.”

Once the business analyst was made available and had completed the first pass analysis he returned to Dale and asked “Does anyone have any idea how big these changes will be?” Now, with the combined voices of the business analyst and the business owners Dale was able to span the boundaries separating the business and IT. As Dale commented:

Once the planning was complete, a lot of my role was just about ensuring that IT and the business continued to work together to deliver to the agreed outcomes. We micro-managed some key users in order to meet deadlines. We went around major blocking stakeholders who were resistant to change; revisiting them periodically to wear them down! In the end the business and IT actually enjoyed working together, and there was a definite feeling of a joint achievement of reaching a common goal.

What we learned

I asked Dale to reflect on what she had learned from the experience. Here are her thoughts:

• Keep project progress as transparent and efficient as possible – we held consistent, regular, and tightly run meetings with key stakeholders across the organisation.
• A good BA is essential – there were weeks it felt like he and me against the world – and then we’d solve something complex and it was thrilling.
• Good planning at the front end always pays back. We had a long (first year and a half) research and planning lead up before formally initiating a twelve month project.

And finally, and I suspect this in-part reflects Dale’s very modest, self-effacing style:

• Not to take myself too seriously! I told myself, there are some very smart people out there, and my role as PM is just there to provide a service. So remain hands-on, stay pragmatic, and keep on IT’s good side!

Our thanks to Dale Porter of Afro Ant for taking part in the Success Stories Shared initiative.

This Success Story Shared comes from the experiences of project manager LT. The aim of the restructuring programme, which LT headed up, was to create a single business for the continent that was completely aligned and integrated. Previous structures had all the countries on the continent operating in silos. The objective of the restructuring was to:

• Create a bank with a single identity in Africa, operating across 12 geographies;
• Allow for centralised operations with standard processes;
• Build co-ordinated systems thereby driving high levels of inter-operability and collaboration;
• Ensure a common and consistent customer experience ; and
• Prevent duplications within the country structures and encourage organisational effectiveness.

The financial services organisation retrenchment project 1 (ARP1) had been put on hold, but it was clear that the project would need to be re-started and that a new approach was essential.

The trouble was that ARP2 was likely to have even more difficult challenges. ARP1 had left staff and unions disillusioned and not trusting the intentions of the organisation and even more resistant to functional changes – relationships with key stakeholders were at an all time low. This was a high profile project and its failure to restructure the organisation and to align the organisation to global best practice, as well as the feeling of mistrust created across the company, was at risk of negatively impacting upon this financial services organisation’s reputation both locally and internationally (at the time of the restructuring, there had already been a merger between international and local entities) .

Moving back on course – righting a misdirected ship

When LT joined the team as the project manager she needed to identify what had gone wrong in ARP1, use these lessons learned to ensure that ARP2 was structured appropriately but additionally she must also deal with the “baggage” inherited from the previous project with respect to mistrust and reputational damage. She conducted one-on-ones with all the key stakeholders involved in the project to understand the nature of the problem in depth.

ARP1 had been led by the Head of HR for the area but it was clear from LT’s review that it had been conducted more as a business-as-usual initiative than as a project or programme. As she commented – “it was almost as if by putting a very senior person in charge it had been assumed that everything would just happen by virtue of seniority.” This was clearly not the case. The HR Executive who led this initiative was dismissed (a casualty of the process) because of the manner in which the project was mismanaged.

LTs first actions were to structure the project around a series of work-groups – get plans in place and clarify roles and responsibilities. She utilised the existing team members and based on her knowledge from the one-on-one discussions, set up teams who were commissioned and contracted with outcomes clearly defined. It was clear to LT that to be successful ARP2 had to be structured less around deadlines and more around the building of effective relationships. One key lesson in stakeholder management was to get senior managers to understand the importance of managing the process and rebuilding relationships as opposed to chasing project timelines.

Stakeholder engagement is key

Three key work groups were set up focusing on ensuring appropriate engagement with stakeholders utilising the right skills and levels of authority to ensure that stakeholder relationships could be facilitated (and in some cases repaired).

Team 1: Unions, external media and senior stakeholders within the organisation. It was important here to have people with excellent facilitation skills while at the same time ensuring that the appropriate levels of authority in the organisation were represented in this group. The unions in particular needed to be convinced that there was real commitment from senior management to work with them to make this work for all. Media releases had to be prepared and issued to ensure that communication was controlled and not left to the devices of snippets of gossip from various social media sites. Senior leadership in the organisation had to be kept up to speed (daily) to prevent them reading or hearing about this project via mainstream or social media sites.

Team 2: Focused on staff personal needs. This group included experts able to support people through the traumas associated with retrenchment. These were the original group of Human Resource professionals. The difference with approach ARP2 was that they were equipped with detailed plans on how to deal with the consultation process (each impacted staff was consulted and presented with the opportunity of applying for a related vacancy within the organisation; remaining on the retrenchment list or early retirements for those who qualified). During these consultations, professional psychologists were on hand to offer their services as and when required.

Team 3: Focused on policies, reward and remuneration – this group included specialists staff skilled and knowledgeable in the legal, reward (payroll), pension, medical aid and other HR considerations required by the impacted employees

Following consultation with the unions Team 4 emerged.

Team 4: focused on looking for opportunities for channelling vacancies and positions available in other parts of the financial services organisation into the project provided possibilities for employment of staff at risk of retrenchment.

Coordination of the inputs was through a 2-tier governance structure. The working committee consisted of selected representatives from the teams. This group had a key role in evaluating suggestions, taking into account across group perspectives and putting forward recommendations for actions to the steering committee and who ultimate decision making responsibilities.

ARP2 has been a success – a major accomplishment when you consider the additional challenges the projects had to face in taking over from ARP1.

Lessons learned

In summarising the lessons learned, LT highlights the following points:
Focus on stakeholder engagement strategies. This was a stakeholder-led project. It was more important to define a project that resulted in a successful stakeholder journey than a project simply focused on delivering a solution within pre-defined constraints
Be sensitive to stakeholder agendas and look for ways to optimise relationships and delivery. Team 4 focused on channelling vacancies back into the restructuring projects. This turned out to be a major win-win. The organisation management had listened to union’s concerns and showed evidence of putting real energy and commitment into finding solutions that benefitted everybody.

Governance is key, but it must not be isolated from the key concerns of the stakeholders. The working committee (and the selection of the representatives in this group) ensured that governance was grounded in the realities of the needs and demands of the organisation’s stakeholders across the group.

Business owners are experts in their respective areas and should not be appointed to manage projects merely because of their seniority. Projects must be managed by project managers. Period!
Project managers must understand that, for most people, change projects are very different to systems implementation projects. No amount of schedule compression or schedule crashing (throwing additional resources at the project or reducing the project schedule) will resolve the matter. People projects are about managing the process to successful conclusion and not to project deadlines.

What do you think?
For further information on the Success Stories Shared initiative click here.

If you would like to share your success story you can email info@citi.co.uk

For further stories you can also visit http://www.pi3.co.za/success-stories-shared and http://www.virtualprojectconsulting.com/success-stories-shared/

Project Challenges

The company was not a convert of formal project management methods and was, at the time, using a lite version of PRINCE2. The translation of strategy into an executable plan whereby stakeholders’ visions of success as a single and agreed common understanding, was particularly difficult.

What worked well?

The successful outcome of the project was based largely on the company’s strong corporate governance working to achieve the strategic objective which was to re-capture its market share. The PRINCE2 Board structure proved to work well with decision makers working quickly and decisively.

Highly effective skilled specialists collaborated regularly by sitting together, resulting in fewer meetings than normal and a cohesive, integrated team.

Dealing within a marketing environment, the team had to adopt flexible project management processes, translating PM terminology into business terms, with ‘risks and issues’ translated into ‘considerations and opportunities’ and the project plan becoming the ‘cycle plan’.

Lessons Learnt

In retrospect the project management team learned that, in spite of the size of the organisation in question, which is governed by bureaucracy, the project team achieved a quick turn-around time from decisions to implementation. The lesson learnt from this is to prevent delays with decision making by global stakeholders, the project plan included a schedule indicating the decision makers’ levels of responsibility in the chain of command which proved to be an invaluable time saving measure.

While the organisation values and uses the formal PRINCE2 approach, here it was crucial that this approach was adapted by the project manager to meet the demands of this specific project in order to achieve the objectives and desired results.

What do you think?
For further information on the Success Stories Shared initiative click here.

If you would like to share your success story you can email info@citi.co.uk

For further stories you can also visit http://www.pi3.co.za/success-stories-shared and http://www.virtualprojectconsulting.com/success-stories-shared/

The topic for the day was – Agile in the P3 environment: reviewing the key features of Agile development and examining whether they can be usefully extended, applied or find parallels in project, programme and portfolio management

The topic for the 35th meeting of CITI’s centres of excellence club (CofEe) was – Agile in the P3 environment: reviewing the key features of Agile development and examining whether they can be usefully extended, applied or find parallels in project, programme and portfolio management.

The day began with an introduction from our host Ian Santry, Head of programme management, best practice and capability at the Home Office. This was followed by some questions from Nick Dobson to stimulate thinking and discussion around whether Agile has real merit in project, programme or portfolio management.

Our first presentation was delivered by Derek Homer, Agile Delivery Manager from Bookatable.Com. Derek has drawn from his extensive experience in Agile product development at Workshare, Nokia and BBC. The main message from Derek’s presentation was that we should not confuse Agile with a project management methodology; it is rather a product development methodology. Whereas Agile provides a mindset that may be suitable for delivering products in some contexts, it does not work well as an approach for managing a project.

The second presentation was from Natalie Jones, Head of Projects at the Home Office. Natalie outlined how Agile was used successfully as a new methodology for software development within the Immigration Platform Technologies Programme. Natalie highlighted the particular challenges of changing the mindsets not only of management but equally of the product managers and software developers. Natalie concluded that although Agile does not come free of challenges, she sees no turning back to other methodologies for product development.

The third presentation was from Phil Bradbury from Transport for London (TfL). Phil outlined how Agile is used within the project management environment at TfL. An important message that emerged from Phil’s experience with agile is that governance in the product development environment should mirror the philosophy underpinning Agile. Phil also emphasised the critical need for changing the mindsets of people working in Agile environments.

Members then were invited to participate in a workshop where they discussed one of four themes:

• Agile experiences in the workplace
• When is it appropriate to use Agile in a project?
• What are the costs and risks of Agile?
• Guidelines for running Agile projects within portfolios and programmes.

During lunch, members were also invited to participate in two surveys. The results of these surveys together with all presentation slides and workshop out puts are available to members at the usual web-site.

Please note: membership of the club is only gained once you have attended a meeting.

Thank you to our guest speakers, all members and a special thank you to our host Ian Santry who helped ensure the day was a great success.

Survey results

Survey one – Measuring progress

Survey one attempted to establish the differences in reporting metrics between Agile and conventional projects. Members were invited to identify which metrics they used to monitor progress in both Agile and non-Agile project environments. The response was equivocal; both types of project make a practically identical use of metrics. The only exception was where metrics were specific to, and could therefore only be used in, an Agile environment (e.g. ‘business value assigned to stories’ and ‘sprint backlog completion rates’).

This seems to imply that there is little differentiation of reporting of progress between different techniques and traditional metrics can be applied to Agile product development.

Survey two – How have organisational frameworks been adapted to accommodate Agile?

This survey was aimed at assessing what proportion of change delivery projects were being run through Agile and, as the same time, the extent to which the governance and structuring mechanisms were altered to accommodate Agile approaches.

A minority of all the projects represented were delivered with the application of Agile approaches and in the majority of instances where projects were being delivered through Agile approaches no changes had been made in project governance structures or monitoring to accommodate this. This is somewhat interesting in that it could either suggest low-levels of maturity in the thinking about the roles of governance structures and monitoring in project delivery; alternatively it could point out an implicit recognition that we don’t need to change project governance structures to accommodate the subordinate Agile product development lifecycles.

Workshop sessions

Four workshops were set to frame discussions between club members. Groups were self directed and generated flipchart output which was summarised in plenary session. The themes and outputs generated are summarised below.

Workshop 1: Agile experiences in the workplace
The first workshop asked members to draw on their Agile experiences in the workplace identifying success stories and cautionary tales on the levels of: (i) product development; (ii) projects; (iii) programmes; and (iv) portfolios.

Most of the success stories arose within the product development and projects environments whilst the cautionary tales surfaced in the attempts to apply Agile approaches in portfolios and programmes.

Success stories in using agile revolved around:

• Incremental product development: Agile allows product managers to start small and incrementally build on success (success brings success)
• Engagement: Agile helps in engaging users and in setting expectations early

Cautionary tales highlighted challenges around:

• Value: Agile is not a panacea for all type of projects and for all type of change
• Skills shortages: difficulties in finding contract resources, while training of existing resources is not easy
• Governance: difficulties in establishing governance structures appropriate to the challenges of applying Agile approaches in complex management environments.

Workshop 2: When is it appropriate to use Agile in a project?

The second workshop asked members to identify when it is appropriate to use Agile in a project.

Emerging concepts from this workshop included:

• Clarity of requirements; members identified that Agile may be useful when projects are building new products or when requirements are ambiguous or fluid
• Type of project: while Agile can be particularly suitable in IT projects, members found the usefulness of Agile in, for example, transformation of people’s behaviour is highly dubious
• Team location: members emphasised that co-location of Agile team is preferable, although not essential. The observation being that it was less effective with geographically dispersed teams
• Project constraints: members emphasised that Agile is not appropriate in fixed cost projects for instance. Although it is possible to cost constrain Agile approaches by pre-determining and establishing the funding of a given number of sprints.

Workshop 3: What are the costs and risks of Agile?

The third workshop challenged members to discuss what costs and risks are associated with Agile.

Emerging concepts from this workshop covered:

Concepts around cost of Agile:

• Agile is perceived to be quicker and cheaper.
• Whereas, conventional methodologies (e.g. waterfall) can have hidden costs (e.g. user engagement), Agile makes this explicit. The need to back-fill users’ roles whilst they are engaged in scrum activities can be significant

• Becoming too obsessed with the methodology (madness of methodology) as some organisations now go Agile as the ‘default setting’
• Fragility: members emphasised that some organisations claim to be doing Agile but not really doing it!
• Product owner: there was also recognition among members of the additional risk associated with the quality of the ‘product owner’, who is key in Agile development
• Co-location: members also highlighted difficulties with running off-shore or remote working Agile development
• Business context: the predominant risk identified was that the technologists and users may take control of the deliverables and their development in isolation of the business context, purposes and objectives; that is to say they could usurp the role of governance and project management

Members stressed additional points around the value from Agile, which are discussed below as part of ‘interesting observations and questions’.

Workshop 4: Guidelines for running Agile projects within portfolios & programmes

The fourth workshop asked members to discuss guidelines for running Agile projects within portfolios and programmes.

An interesting observation is that both teams who participated in this workshop went back to basics by questioning ‘what is Agile’ in the first place? Members stressed that even now ‘we are not clear on what Agile means’; there was clearly an apprehension that Agile as a formalised product development lifecycle is often confused with a more general management ambition to be agile (i.e. flexible and quick) in performance. In short that Agile is very close to being a ‘buzz-word’.

Some members suggested that Agile is ‘a way to manage uncertainty’ at the level of projects and programmes and that it might be applicable for use in prioritising projects within a portfolio; however concrete examples or a clear explanation of how this might occur were not forthcoming.

Emerging guidelines for running Agile projects from this workshop:

• Choose the right people (best people!)
• Communication within teams and with the business is key
• Define clear roles and responsibilities (determine RACI up front)
• Be clear on what you want, then measure it!

The energy and participation in all the work groups was high with individuals freely exchanging views and opinions.

Some ‘interesting observations and questions’ emerged from the deliberations of the afternoon which can be summarised as:

1. Culturally Agile is ‘mandating’ user involvement, but shouldn’t this be the case in all well-run projects as Pinto and Slevin have been telling us since the 1980s?
2. Culturally Agile accommodates the mindset that some products may ‘not succeed’ and it structures for ‘fail fast’, but shouldn’t this be the mindset in all projects? Projects are, after all, speculative investments.
3. Isn’t it essential for project managers and sponsors to ask the question: what problems Agile (in contrast to other approaches) are supposed to solve?
4. Are all the ‘good’ things that come with the Agile methodology (e.g. user engagement, collaboration, multi-disciplinary teams, clear communication, well-defined roles, focus on the project goal) not possible with other project management methodologies?
5. Does agile have to be the only approach or can projects have a hybrid approach where it can start with agile then switch to waterfall for instance?

Indeed this last question underlies the overall conclusion of the day which is that Agile is a product development lifecycle and approach for the iterative development of products (e.g. software) in collaboration with the users and, in the correct circumstances, can prove exceptionally effective. However it is not a project management approach and attempting to apply it as one demonstrates a profound misunderstanding of the differences between project management and product development management – they are not the same.

What was going wrong? From all accounts the bank processes and policies were being executed effectively – but they just were not having the right effect.

With tight timescales and the need to make rapid changes it was decided to appoint a project team. Bakr was to advice the team from a knowledge management perspective and to provide support and guidance to the new project manager who was business knowledgeable but relatively inexperienced in projects.

The project would start with an investigative stage to surface the root causes of the problems. The change director, who was also accountable as the business sponsor, was keen to select the best front-line staff to be part of this team. But Bakr was not convinced – these people were the ones using and supportive of the current processes – the processes which were already shown not to be working. Instead he put forward the case for picking a ‘maverick’ team – the staff who had been complaining about the approaches – the ones who were always saying there was a better way.

At first the management team were sceptical – after all these staff were the difficult ones – the ones who were not performing under the current approaches. Bakr was persuasive and got his team of eight mavericks who were interviewed and selected as staff who doggedly questioned the way things were done.

This kind of team is not the easiest to manage and careful consideration was put into structuring the environment and the team engagement. For the investigation to be effective these people were encouraged to try things out which were out of the norm, and sometimes even counter to standard policy. That meant they had to be empowered to take the action necessary and that the management team round them would support them through this process.

The team were co-located in one bank site and the top most difficult clients cases were selected for their attention. For a period of 3 weeks – each day the team dealt with 50-60 cases – working on the phones from 8am to 3 each day. At 3pm the reflection and analysis began. In a room full of flip charts Bakr and the project manager facilitated the gathering of the stories from the day. What was going wrong – what practices seemed to work, what could they try doing to sort out the problem? The team were encouraged to think out of the box and to put themselves into the customers’ shoes – “if it were you – what would be good for you?”.

As an example, in one story the manager related how a client was extremely upset by the attitude of different staff who contacted him. He was paying for repayments on a loan for his son’s bike and was capable of paying but had been so irritated by the banks approach and conflicting messages, he resorted to withholding payments. The team decided to assign a single liaison officer (from this experimental team) and no other person was allowed to communicate with the customer. Within a short time the problem was turned around and payments started coming in.

Within one month the success achieved by the team was phenomenal on these most difficult of client cases. From a starting point of just 22% to a massive 94% of payments being paid and back on a defined payment schedule.

This investigative approach transformed a group of mavericks into a team who were passionate and empowered to take forward and replicate the lessons learned in other operational areas. It was this energy and new found belief in the individuals in the team which allowed them to make the tricky task of operationalisation – taking the new processes back into operation – possible.
In reflecting back on this rewarding project, Bakr identified three major learning points:

• Before initiating a project, it is critical to recognise sources of complexity and to prepare the team (including sponsor) that such complexity often requires innovative, experiential approaches for problem-solving; rather than over-depending – often unsatisfactorily – on standard project management approaches
• In selecting the project team, it is important to understand that suitable change agents are not necessarily the best performing staff; they are more likely to be the most eager for change (the mavericks)
• The planning and delivery stages in complex projects sometimes require iterative cycles of action learning, as project deliverables are unclear at the time of initiation.

What do you think?

My thanks to Bakr Zade for sharing this story.

For further information on the Success Stories Shared initiative click here.

If you would like to share your success story you can email info@citi.co.uk

For further stories you can also visit http://www.pi3.co.za/success-stories-shared and http://www.virtualprojectconsulting.com/success-stories-shared/

The new offices were to be open plan. Many of the staff in Cellnet had moved from British Telecom (BT) where personal offices were common and indeed expected. There was no doubt that there would be some resistance to the change. “We didn’t just want our staff to put up with the change. We wanted them to exploit the opportunities available for improved communications within and between working groups.” Eddie recognised the challenges the programme would bring. He needed to understand the project context – the environment in which it must succeed. Employing tools such as PESTLE and stakeholder (power and attitude) mapping, he created the first draft plans. These focused on the impacts that had to be achieved for the project to meet the Managing Director’s aims. Not on how it should it be done, but what changes were necessary and who needed to be influenced.

Now he felt ready to meet with the people who would really understand the potential issues and challenges to be faced. A wider project team of around 40 people were selected from across the business and the vendors to help with the development of practical solutions to achieve the programme objectives. Initially Eddie engaged on a one-to-one basis with all team members, listening and gathering information. Then he brought selected team members together to brainstorm ideas. This workshop, rather like a risk workshop, focused on what could go wrong. What can we do to reduce resistance? What won’t people like? What can we do to anticipate and reduce resistance?

A lot of great ideas came through. Some were more practical than others. One action that was very successfully adopted from the workshop was the setting up of visits to the new HQ site as it was being constructed. Staff could see their new working environment take shape. They could start to get used to the new accommodations and contribute ideas about how to make it work for them. More detailed potential problems were identified such as the control of air conditioning. In your own office you can control your ‘climate’. This would be trickier in the open plan offices and could lead to increased staff conflict levels. A decision was taken early-on to allow some control of temperature through zoning of the air condition controls.

It’s this kind of detail which illustrates the importance of engaging with the stakeholders very early in the process. In this way the design and build could take into account these suggestions. Imagine trying to change the aircon after all the wiring had been done! Eddie has been in project and programme management for many years. This was an early programme for him and he felt the big learning lessons then were:

• Get the planning going as early as possible.
• Make sure everybody is working to the same plan – that means engaging and communicating with a wide range of stakeholders, the business, users, vendors and contractors. “Often the comment I got when I tried to engage was – we’re not ready to talk yet. But you can never be too early to start to share information and identify potential interdependencies which need to be dealt with early.”
• A holistic approach to planning is essential. Eddie is a fan of the systems thinking model. Each part of the ‘system’ is interconnected and you need to understand how the interconnections work and how this affects the management and control of the programme.
• Engage the team – the stakeholders who will be impacted and who have a vested interest in the programme/project. They really “bring you back to earth” and make it clear what will, won’t and might not work.

What do you think?

My thanks to Eddie Fisher for sharing this story.

For further information on the Success Stories Shared initiative click here.

If you would like to share your success story you can email info@citi.co.uk

For further stories you can also visit http://www.pi3.co.za/success-stories-shared and http://www.virtualprojectconsulting.com/success-stories-shared/

If you would like to share a success story – then please contact info@citi.co.uk or visit the dedicated area of our website here http://www.citi.co.uk/about-us/success-stories-shared/