We are now ready for the final article – at least for now – in my Project Success Series. As with any blog, I reserve the right to come up with new content to add to any series like this so consider yourselves forewarned.

 

 

 

 

To recap, the premise here is that there are four main questions that your company CEO could ask you concerning whatever highly visible or mission critical project you are currently managing or just completed if you were to run into him in the hallway. Understandably, since this is your CEO, it is best for your career if you can be ready with meaningful and accurate answers to these questions and the proof to back them up. These questions are:

 

 

 

 

 

 





     
  •  
  • Was the project on budget?




  •  
  •  
  • Was the project on time?




  •  
  •  
  • Was the customer satisfied?




  •  
  •  
  • Did the project deliver a usable solution?




  •  
  •  

 

 

 

 

 

 

Part 1 dealt with the question concerning whether or not your project was on budget. In Part 2, we dealt with keeping your project delivery schedule on track. Part 3 dealt with the concept of customer satisfaction.

 

 

 

 

Now in Part 4 we will cover the concept of delivering a workable solution to the customer. And not just one that is bug-free, but a solution that the customer wants and needs and it’s your job to deliver that even though we all know that the customer often isn’t truly aware of what it is they actually need. Frustrating? Yes! Let’s discuss ways we can ensure that we’re delivering the best possible solution for the customer.

 

 

 

 

Never Assume the Customer Knows What They Want

 

 

 

 

I’ve covered this one elsewhere, but it’s an easy trap to fall in to. After all, they’re the customer and all we have to do is build to their requirements, right? Wrong! Be sure to ask the right questions up front and don’t be afraid to ask the customer to go back to their end users and SMEs and make sure that they understand what the final solution really needs to be. Many times though don’t truly know that when the engagement starts. If that is the case, one of two things happens:

 

 

 

 

 

 





     
  •  
  • It becomes apparent part way through the engagement and then the customer is faced with change orders, a stretched out timeline, budget overruns due to re-work, and a lot of frustration for both teams.




  •  
  •  
  • It doesn’t become apparent until deployment when the end user finally gets their hands on it and it’s not what everyone dreamed it would be. Sure, you built to the customer specs, but the lasting legacy is that the customer has an unusable solution and the finger often gets pointed at you and the delivery team.




  •  
  •  

 

 

 

 

 

 

Assemble a Skilled Delivery Team

 

 

 

 

As with any engagement, the more applicable skills your team has for delivering on the engagement, the better chance you have for success. With a good SOW and detailed requirements, you’ll know what skills you need. Fight for those with your management and work hard to keep that team engaged…meaning manage the schedule tightly, etc. Less ‘down’ time during the engagement means less likelihood you’ll lose skilled resources to other projects.

 

 

 

 

Don’t go overboard acquiring the best skill set in each area of need if that’s unnecessary because you’ll end up costing the project extra $$ that aren’t necessary. Protect profitability by going after the right skill level for the need and then work hard to manage the resources well and keep them engaged on your project.

 

 

 

 

Track Requirements As Though Your Life Depended On It

 

 

 

 

During Exploration and Design, map out the customer requirements well using a Requirements Traceability Matrix (we’ll cover that in another article) and manage those requirements closely. Keep track in the matrix of where those requirements are implemented in the final solution. Missed requirements mean a solution that doesn’t match your customers documented needs.

 

 

 

 

Test and Re-Test

 

 

 

 

This is an easy one. Have the customer build their own test cases and also use those during your own system tests prior to UAT along with your own test cases. Make sure the customer has solid, knowledgeable resources engaged for the User Acceptance Testing (UAT) sessions and definitely get their signoff on UAT once it’s completed.

 

 

 

 

A well-tested system goes along way in ensuring that the delivered system will work for the customer.

 

 

 

 

CYA – Get All Signoffs Just In Case

 

 

 

 

This one can’t guarantee that the customer is getting what they want, but it does help guarantee that even if they don’t, your butt is covered. Signoffs on requirements, UAT, and deployment go along way in removing blame from you if the shoe drops. Not that we ever want an unsatisfied customer. But the only thing we want less than an unsatisfied customer is an unsatisfied CEO or PMO Director who signs our paychecks. Get signoffs…you’ll sleep better at night…I promise.

 

 

 

 

This concludes my Project Success Series…at least for now. I’d appreciate hearing your comments and any additional areas that you think should be included.