This article was originally authored by me for the PM Tips website and published there on 7/11/09. Go here to view the original article.
In school I hated to turn anything in misspelled or with handwriting that didn’t look how I wanted it to look. I took me a long time to ever start using pens because I always wanted to be able to erase and correct. Ok, I may have been a little OCD about that.
Even with my articles, I run them through spell checkers first – though that doesn’t catch a correctly spelled word that may be out of place or out of context. I try to re-read everything, but sometimes things slip through.
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.
Bad Example
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.
Ok…so 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.
Never Assume
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
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.
In school I hated to turn anything in misspelled or with handwriting that didn’t look how I wanted it to look. I took me a long time to ever start using pens because I always wanted to be able to erase and correct. Ok, I may have been a little OCD about that.
Even with my articles, I run them through spell checkers first – though that doesn’t catch a correctly spelled word that may be out of place or out of context. I try to re-read everything, but sometimes things slip through.
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.
Bad Example
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.
Ok…so 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.
Never Assume
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
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.
RSS Feed
