peer-review

Use Your Project Team for Peer Reviews

I hate mistakes. I hate misspellings and grammar issues – though I’m probably crossing some dangerous lines in this article alone. Most of all I hate leading a project and turning error-riddle deliverables into the anxiously awaiting client who is paying for them and who’s every thread of trust is built into me and my team providing quality and timely output to them.

 

Do you hate error-prone project deliverables as much as I do? Have these cause you problems on one or more projects so far? Read on…hopefully this will educate us all on ways to avoid providing anything less than stellar output to our customers going forward…

 

Proof and Test. The same care needs to go into our project deliverables. Proof, proof, proof. Test, test, test. When you hand a deliverable over to the customer – unless it’s understood that this is an early draft – then you’re telling the customer that this is done and the best I can do. It better be correct. It better be accurate and read well. And it better be free of simple typos, for crying out loud.

 

A very bad experience. I had a project with a major US airline where I had two business analysts working on the project. One was more experienced than the other and was really acting in a mentoring role to the other one. The less experienced one was the BA actually doing most of the work. The understanding was – for my team AND for the customer – that the less experienced BA’s work was being overseen and proofed by the expert BA.

 

When we had to go through 5 iterations of the Business Requirements Document (BRD), going to the customer with typos, inaccurate table of contents items, misspellings, missing graphics, etc. you can imagine how quickly the customer satisfaction we were building started to disappear! The customer couldn’t understand – and rightly so – how a team of 5 skilled technical resources (including me as the Project Manager) couldn’t turn in an accurate BRD without typos. Customer confidence dropped like a rock.

 

Avoid assuming…you may very well regret it. I was in the wrong for assuming that between two experienced Business Analysts that they could get a document handed over to the customer that was free of typos. I was busy, everyone was busy, and I expected it to just get done and be done right. It wasn’t until we started incorporating peer reviews for every single deliverable that went to the customer that we started handing over error-free documents. We conducted peer reviews on the BRD (finally), the Functional Design Document, the Test Plan, and every piece of information that went to the customer in written (or electronic) form from that point on and we got it right. I even had the full team review the status reports, weekly status meeting notes, revised project schedule, and issues/risks lists before sending them off to the customer in order to ensure that the customer did not see any more incorrect and unprofessional submissions from our team.

 

Summary / call for input

 

Never take for granted that everyone cares as much as you do about the output that they deliver. Yes, it has their name on it, but if it’s your project it also has your name on it and everything comes back to you as the Project Manager. Work hard to ensure that emails are accurate and have the proper attachments the first time, that status reports are accurate, that status notes are accurate, that your project schedule has been updated with everything that the customer is expecting to see, and definitely make sure that the documents you deliver as part of your engagement are free of the simple errors and typos that make a professional team look very unprofessional.

 

This won’t necessarily increase customer satisfaction because it’s really just an overall expectation they should have anyway, but at least it won’t decrease customer satisfaction and that is definitely a good thing.

 

Have you had negative experiences with you or your team turning in error-prone output and deliverables on a past project? What did you do to stop that practice and help ensure quality going forward?

 

 

About Brad Egeland

Brad Egeland

Brad Egeland is a Business Solution Designer and IT/PM consultant and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Creative Design, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. Brad is married, a father of 11, and living in sunny Las Vegas, NV. Visit Brad’s site at http://www.bradegeland.com/.