I’ve been thinking about authenticity and the way that Project Managers [PMs] and PMO professionals present themselves in the professional arena. I saw a LinkedIn post a while back highlighting a vacancy advert requiring that the PM had previous experience of managing ‘ugly’ projects, and recounting experience of having interviewed multiple PMs whose projects had all run perfectly.

Substance over Style

I agree that the PMs most likely to be most able to cope with a difficult project are those who have faced challenges in the past, not those with a shiny, sparkling track record. But, through a fear of being seen to be anything less than perfect, PMs often withhold their challenging experiences. Volunteering these is tantamount to saying “Don’t make the same mistakes that I did”, and I suspect a significant proportion of PMs prefer to learn their lessons in private whilst publicly declaring that everything went perfectly.

I think this has a root in the current climate of social media, with its palette of airbrushed selfies, polished profiles, and personal branding. I think it could be useful for the Project Management profession if we all shared more of our stories about the challenges we’ve faced, how we overcame them and the lessons we learned as a result.

So I’ve launched the Campaign for Real Project Managers (or #CAMRPM). It’s free to join, all you have to do is publicly share your “war stories”.

I’ll show you mine…

• It was all for nothing: A UK subsidiary of a French company was recognised as a global leader of PM maturity in the organisation. As the PM methodology was becoming unwieldy, the UK decided to streamline it, and reported the initial learnings to France for potential inclusion in their own forthcoming methodology development. Personnel changed both in the UK and France, and contact between the UK and French methodology teams was lost. The UK team made multiple attempts to contact the French team, but it appeared they no longer existed. So the UK team continued developing a streamlined methodology that was well supported by PMs and CxO stakeholders alike. Shortly after this was launched, France got in touch. They had launched a new (mandatory, heavyweight, centralised) methodology, and the UK was now six months late implementing it!
  Lesson Learned: Never underestimate the tendency of large corporations to use a sledgehammer to crack every nut.
• No-one wanted the project: The project was developing a range of simple ‘white label’ insurance products to reduce time to market from months to weeks when onboarding a new small distributor. A project delivering benefits like this should have enjoyed wide support, but in practice even the Sponsor was only lukewarm. The project was delivered, but it was a struggle the whole way. Soon after Go Live, a major strategic project was launched that effectively enabled much quicker and easier new product launches for the larger distributors. The organisation’s CxOs would have known about this, and would probably have been distracted by it during the earlier, smaller project.
  Lesson Learned: When support for your project is low, it may be for environmental reasons rather than anything you have or haven’t done.
• And another thing: The same project involved the development of a sales website with an entirely new, standardised architecture. As the team developed this new site for one product, other product owners asked for their product to be included. Initially, the team tried to accommodate their requests, but it quickly became apparent that if all the requests were accommodated, getting the website running with the originally requested functionality would be delayed. The team had to tightly contain scope in order to deliver.
  Lesson Learned: Requests for additional scope items can bog a project down. Instead, use a Change Request process, get requests prioritised, and negotiate time / money allowances for each additional scope item.
• Deficient Data:  Shortly after launching a new insurance sales website, a customer complained their policy had an incorrect start date; this had implications for all customers using the site. It was deduced that of the several methods of date entry on the site, one was omitting a leading zero from single digit months, leading the policy system to misinterpret the start date. The website was corrected to prevent any more errors, then other affected policies were identified and rectified manually. The problems was resolved before all but one policyholder (the one that raised the problem) realised it even existed.
  Lesson learned: First identify the cause of the problem and implement a solution that stops any more problems being created; then resolve the backlog.
• Deceptive Data:  The recruitment process for a new employee narrowed the choice down to two candidates who both looked good. Candidate #2 was more personable but the role was offered to Candidate #1, who had better test results. As soon as he started, bad reports were received on his performance. Requirements were clarified and specific performance criteria were set. The situation didn’t improve so his probationary period was terminated, and the position was offered to Candidate #2, who fortunately was still available (and is still there several years later).
  Lesson learned: Sometimes the data contradicts your instincts and sets off your internal alarm bells. That is when to trust your gut feel.
• Sponsors developed Cold Feet: A design-and-manufacture project was of minor importance to the Client, but was critical to the Supplier. Shortly after commissioning custom moulding tools to produce bespoke components, the Client restructured, reducing the project’s priority significantly. Needing to keep the project afloat, the Supplier prepared a financial analysis on the rest of the project, comparing the exit cost with completion cost, and comparing the benefits of the two approaches. This was communicated to the Client often, to show the (steadily improving) case for continuing.
  Lesson learned: You can outline options and make recommendations, but in the end the Sponsor decides what happens as it’s their money and their project.
• Design under pressure: The project involved holding liquids under pressure in a tank containing a clear plastic window. Some stakeholders wanted to cut costs by skimping on the strength of the window, but the design team wanted to design for safety by conforming to well-respected guidelines. Wanting to convey the forces concerned, the PM worked out the force on the window was equivalent to the weight of a small elephant. The PM commissioned a simple paste-up image of an elephant standing on one leg on the tank window. This made the point successfully in subsequent design discussions, and the window was produced to established design standards.
  Lesson learned: Using the right image really can be worth many words.
  
• Is it ‘good enough’?: When producing specifications for finished units, the custom & practice was to produce a signed off sample as a quality reference. In order to secure Client sign-off, these samples were often of such high quality that meeting the needlessly high standard generated rework and increased production costs. One PM adopted a more pragmatic approach, ensuring that samples for Client sign off exhibited minor but common imperfections, that should have little to no impact on performance in use. At sign-off this prompted a conversation about the acceptability of that imperfection, and the potential cost implications of eradicating it.
  Lesson learned: Having a ‘grown-up conversation’ during specification-setting makes for more realistic acceptance testing or performance monitoring later. Use ‘good enough’ rather than ‘perfect’ as a quality standard, as the Client doesn’t pay for the difference (you do!)

…Now you show me yours

So those are my stories; I’ve shown you some of my scars. Now how about sharing some of your scars?

Why not join the Campaign for Real Project Managers (#CAMRPM) by sharing your stories in the comments (or post a link to your article elsewhere, and use the #CAMRPM hashtag), and let’s have a bit more authenticity in Project Management!

I liked this idea so much, that I created my an interview series around it. In these “Scary Scars Shared” interviews, I ask Real Project Managers to share in around ten minutes the lessons they have learned from managing projects, so that the whole project management community can learn from their experiences.

You can find the entire series at http://bit.ly/ScaryScars (video) and http://bit.ly/PragmaticPMOCast (audio, or search for “Pragmatic PMOCast” wherever you get your podcasts)

If you’d like to share your scars by appearing in one of these interviews, then let me know.

Sharing short, sharp, project lessons interviews like this is just one of the pragmatic pointers recommended in Ken’s book “Learning lessons from Projects: How it works, why it goes wrong, and how it you can do it better”, available from http://bit.ly/KensLLBook

This article was originally published on ESI International’s ‘PM Perspectives’ Blog [now defunct] on 05Nov15