I’ve been thinking recently about authenticity and the way that Project Managers [PMs] present themselves in the professional arena. One recent post on LinkedIn highlighted 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 mistake 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. Yet there are a few stars around today who eschew the photoshopped image going make-up free, and unretouched.
This made me 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 right here, right now, I’m starting 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…
To start the ball rolling, here are a few of my stories, some from my personal PM experience, and some seen from my PMO viewpoint (see if you can guess which is which!):
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.
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 problem 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.
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: Presenting data 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 stories. Now how about sharing some of yours? 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), share on Twitter with the # and let’s have a bit more authenticity in Project Management!