What learning legacy are you building?

Project learning legacies

I’ve just returned from a week in the UK having had some great project conversations.  One thing that really struck me was the emphasis on learning legacies.  This has particularly taken off in the engineering and construction industries where learning legacy portals are being made publicly available. 

These legacy learning sites aim to share knowledge and insights across the profession. As the Crossrail legacy site so aptly puts it – they want to promote a

‘pinch with pride’

attitude to encourage projects to learn from what has happened before.

Our work on lessons learned, which came out of the Success Stories Shared initiative in South Africa, suggested that:

Despite 80% of projects running PIRs, less than 20% of PIR reports were ever re-accessed, and there was little evidence of organisational learning.

Lessons identified only become lessons learnt once the collected knowledge is used in current or future projects. There needs to be a transition space created where a shift takes place, and vital knowledge is not simply stored away in files, not being accessed, but rather becomes implemented on a practical project level. But who is responsible for this shift from lessons identified to lessons learnt and how can it be facilitated?

It is interesting to see in sites such as the Major Projects Knowledge Hub that there is an emphasis, not only on sharing stories but also on connecting networks of experts across the industry.

Perhaps there needs to be a conceptual shift between the process of identifying lessons and actually learning lessons. If learning results in change, then what usually takes place at the end of a project would be the identification of a lesson. Rather than having lessons identified as one of the outcomes of the project, it should be seen as the start of the process that develops the lessons that are genuinely learnt and thus, by definition, implemented.  

In one retail company in South Africa, we have seen this approach embedded in the process of starting a project.  The project motivation documentation requires the project manager and sponsor to agree on which previous projects the new project is most similar.  There must be some evidence that information and learning from these projects have been taken into account.  After four years of this in action, both sponsors and projects managers are unanimous in their view – it is crazy not to do this!

Learning legacy portals

Perhaps the best known and earliest portal in the UK was that set up following the 2012 London Olympic games:

This is now in an archive state but here are some others that are very much alive and worth following:

I’m sure there must be more across the world.  Please do share information about any others you know.

Our new book, Adaptive Project Planning, uses stories gathered from lessons learned in projects across the world. It is now available on Amazon.


When the budget really matters: A church restoration with lottery funding

When Ian Cribbes, took over the project management of the St Edburg’s church conservation work in Bicester he had not quite realized how different it would be from the projects and programmes he had managed for over 30 years for BAE Systems.    The project had a £205,500 budget – somewhat smaller than the multi-million-pound projects he had been involved in his professional career.  This budget came in two phases; phase 1 was for £19,500 and was allocated for the carrying out of development work (the production of plans and reports); phase 2 was for £186,000 and was allocated to the actual works to be carried out.  But, as he is the first to admit, this project proves the point that being small does not necessarily make it simple.  Sometimes tight constraints demand higher levels of capability and attention to detail from the project manager.

The St Edburg’s work was a conservation project to restore its Grade 1 listed building, parts of which date back 900 years and was funded by the Heritage Lottery.  (In the UK work on a Grade 1 Listed Building is categorized as ‘conservation work’ when its purpose is to retain what is there for future generations.  Renovation and restoration, on the other hand, is when work is carried out to take things back to what they were.)

Ian is an experienced project manager and knew he had things to learn as the construction domain, and in particular heritage conservation, was new to him.  What he hadn’t foreseen was how the difference in the funding and the stipulated budgetary control processes would affect the planning and every aspect of the execution of the project.  The budget constraint was absolute – it was this amount and not a penny more!  While the control of spending on commercial projects is important, with most, especially larger, budgets there are usually opportunities for virement – moving costs between account categories.  It is also often the case that there isn’t an absolute cost: when push comes to shove – more money can be found.  This was very much not the case on this project.

Continue reading “When the budget really matters: A church restoration with lottery funding”

Changing IT roll-outs into stakeholder-led implementations

When rolling out new IT infrastructure to a large number of client sites, it is tempting to consider it to be the same project over and over again.  But while the project may be justified in terms of the standardisation of technologies across the corporation, how those technologies get implemented and exploited by each business area may be substantially different.

Philpic1Phil and his team recognised that the crucial factor, the thing that would make-or-break this global project was not the technology but the differing business contexts and stakeholders concerns that each roll-out would deliver into.  A previous attempt at implementation had been a costly failure – the business knew it and needed other options.  Fifty-seven countries impacted;  12,000 applications reduced to just one thousand; the very way that users could access their PCs would change with admin rights removed from all personal computers.  These changes were far-reaching, and their instigation by a central controlling group was unlikely to meet with group-wide excitement and positive emotions!

The business agreed a new approach was necessary.  The first actions taken by the project manager, Phil Urwin, was to send members of his team to visit the twenty hub-countries and establish the stakeholder success criteria.  What would make it good for them at their site… in their words?  Phil’s aim was to convert the technology implementation into a stakeholder-led programme.  Each site visit resulted in a 2-page summary of what mattered to the local stakeholders, and each site was different.  Some reported non-technical users who would need hand-holding –  others reported good technical skills.  Implementation no-go times, PC wants and needs- all captured succinctly in the 2-page mandate for the site implementation.

The rollout project was a large initiative for the company.   At the Head Offices in the UK,  the normal governance structures existed – “these role-based stakeholder engagements were engaged through formal structures, but often there was little interest from them beyond getting a view about the status of the project.  It was with the agenda-based stakeholders that we needed to focus our attention.”  The project established open channels of communication with these groups using webex or whatever medium best suited the participants.  Before and during the implementation this was crucial and resulted in at least weekly meetings.  While the project team took responsibility for the initiation of the meetings, the agenda was driven by the stakeholders – it was definitely their meeting.

With fifty percent of the programme rolled out and four of the largest implementations completed the signs are good.  Customer satisfaction ratings were previously 2-3 and during and post the implementation moved from 4.1 to 4.6.  When asked about the lesson learned from the project, Phil describes two critical areas:

  • A stakeholder-led project. Right from the start, the project outcomes were aligned to the needs and agendas of stakeholders in their own business context.  Phil does not talk about the technology or what it could or could not do – his total focus is on addressing these concerns.
  • Stakeholder-focused, “like-minded team.” It’s not enough for the project and project manager to be stakeholder-focused this attitude and approach must be propagated throughout the whole team. Following the process is not good enough (although the process matters) the understanding and buy-in from every team member is crucial to translating good ideas into a reality on the client site.

Phil Urwin is currently a programme manager with The Grangeside Group.  In September he will be presenting at the New Zealand Project Management Conference in Christchurch on how to recruit the right project manager, develop and keep them. http://www.projectmanagementconference.org.nz/

My thanks to Phil for taking part in the Success Stories Shared initiative.

SSS-logo-smallSuccess Stories Shared is a South African initiative to encourage sharing across the project community. Driven by Louise Worsley & Linky van der Merwe, you can find these stories online on this blog site or at http://www.virtualprojectconsulting.com/success-stories-shared/

If you have a story to share, please do contact us:

  • Louise Worsley: lworsley@pi3learning.co.za

The simple upgrade which wasn’t:

Lessons from upgrading browser software

top-10-reasons-to-upgrade-your-accounting-softwareWhen IT recommended to the business that a simple PC software upgrade was needed, nobody thought it would be a major problem.

Within six months the software would no longer be supported.  Of course, it was a large upgrade – the Head office and over 400 high street stores; a total of 30,000 devices would be affected, but the IT department was confident that there would be no impact on operational systems.  The initial plan was simply to send out the upgrade links to users explaining the necessity of the upgrade and asking each person to follow the link and upgrade.  It was clear early on that this was simply not having the desired effect.  Even when managers were engaged and asked to oversee the implementation, there was an estimate of over 50% of the company not reacting to the emails.

The business change manager appointed knew that a much more structured approach where the software was ‘pushed’ to the devices would be necessary.  He was also aware that this approach would not be universally popular.

First find the PC!

An early problem was identifying all of the devices that needed the upgrade.  While it was clear for the stores, in Head Office there were a whole variety of devices, from laptops to cell phones that might be affected.  It was only a year earlier that the IT department had implemented a similar company-wide upgrade of the operating system – so it was with some disappointment that the change manager found that no accurate record was available of what devices existed and where.  (Authors note – the lack of configuration control of IT devices has been noted in other stories – it just seems too difficult to do, resulting in the repeated exercise of ‘first find the PC’!).

“We thought once we knew the devices the upgrade would be easy.  It turned out to be quite the reverse”, reported the change manager.  One of the key operational systems just would not work with the new browser.  This system was so critical, all changes to it were controlled centrally by a specialist team.  The sad thing was that these implications had been known for some time.  As the change manager suggested, “it was almost as if the IT technical people in the know were too afraid to bring forward the bad news – we should have known earlier about this problem.”

The decision lies in the hands of the business

Every one of the functions in the operational application would be potentially be affected by the upgrade, and there was no way, except through a screen-by-screen check of identifying the implications.  “After eight weeks – we could report was that it should work but with insufficient time for full regression testing the only way to test was to get access to the model office environments.”  As in most businesses, this testing environment is extremely hard to get access to, and the team could not yet estimate how long they would need in the model office.

In the end, it was decided to go to the project board. In this business, this was a very well structured group empowered to make and carry through decision across the organisation.  The change manager prepared and presented two options:

  • Option 1: Stay with the unsupported software until regression testing was complete. Support ended within four months, but it would take 12 months to do full regression testing
  • Option 2: Go-live and fix on failure. Operational risks were assessed and presented.  These were very real risks including loss of income and reputational risk.

The board selected option 2.

A fix on failure approach

The change manager worked with his team to define the approach.  The 80% most common transaction screens were identified, and this was the focus of error checking before going live in a selected store.  Once sufficient usage and fixing had occurred then a national roll-out to the remaining 400 offices would be instigated.  In the meantime planning for Head Office implementation, which involved the more complex identification of devices, would start in parallel.  For the initial store implementation, the upgrade would be applied to all but two devices.  These two devices would then be available to staff to use should there be problems in operation due to the upgrade.

The change manager had chosen to lead the briefings and be onsite during the week of the initial implementation to ensure he was there to help fix things if they went wrong. The implementation “mostly worked,” but there were critical actions, such as being able to print till receipts, which just wouldn’t work.  It took tenacity on the part of the change manager to persuade the IT team of the all the issues that were being faced by the staff.  It took two months to satisfactorily complete the store test implementation with all of the fixes that were required and the to-ing and fro-ing between the project and the IT team.

During this time, the upgrade built a reputation (often unfounded) as the cause of any problems which might occur on any system.  “Oh, that is probably caused by the new software upgrade.”  The change manager recognised that for the wider roll-out to be successful and acceptable, it was essential that a well-controlled and managed store-by-store roll-out be established, and that confidence in the roll-out process was regained.  He insisted the second store implementation should occur in a particular location so IT could be closer to the problems.  “I needed IT to see this, understand the issues faced and react quickly.”

After the early slow implementation, store roll-outs could be expedited with 100 stores implemented in just a week.  The total implementation of all stores and Head Office took six months.

Our take-aways

In reflecting back on the project the change manager identified a number of learning points:

  • Decision-making around this had to be firmly in the hands of the business. Only they could decide what risks they were prepared to expose the business to.  This was done well in this business.
  • Sometimes getting IT to react to problems was hard. “My contact in IT was hard to engage with, but my feeling is that there will always be difficult people on a project – senior and junior – it’s just about finding ways of getting things done.”

And with respect to the Head Office implementation:

  • We found we could not rely on the organisation chart in Head Office to work out who reported to who and where they sat to help us build up a picture of who we needed to engage with. So we started at the top of the organisation, talking with PAs and support staff to identify the people in the top three layers of Head Office. We opened up communications and consulted and worked with this group to agree on the roll-outs.  This worked pretty well, but it turned out there were influential and high energy stakeholders in the lower levels that we missed.  This did prove to be an issue.  Just because somebody is junior does not mean they cannot significantly impact the project – something to look out for on future projects!

This project has been anonymised.  Many thanks to those who helped us in compiling it.  For further information on the Success Stories Shared initiative click here. If you would be happy to take part in this initiative do contact me – Louise Worsley, lworsley@pi3.co.za