I’ve written a lot about requirements and how critical they are to getting a project off the ground and headed in the right direction. In the long run on a project good requirements are important for the following reasons and more:
- Keeping the project aligned with original goals
- Keeping the project on time
- Keeping the project on budget
- Scope management
- Customer satisfaction
- Ease of development and minimizing re-work
Internal Fiasco
So, what happens when you get an add-on internal project for an influential person within the organization and the requirements are somewhat grey? I had a project like this not very long ago. I was asked to run a project with the basic direction of ‘just do it’ along with my other projects and ‘make them happy.’ Fun!
When one of these falls in your lap, you can try to formalize things as much as possible and wrap good project management practices around it, but if the customer (in this case, internal customer) is not interested or willing to participate and at that point considers it frivolous attention to too much detail, what do you do? That’s the quandary…because I can tell you what happens if you don’t do enough.
I thought I was getting my hands around it... I met with the customer on requirements, documented them at the most detailed level I could since I was only working with the information I was able to drag out of them. They were basically ‘approved’ as I had documented and communicated them.
The bad news is that three months later at the completion of this small one-off process improvement project, one area was lacking the proper detail that this customer now wanted. (Notice I’m not going into too much detail here – it would not be in anyone’s best interest nor is it important for the point I’m trying to make.) Forget that fact that I had asked about this particular area of the requirements on two separate occasions and confirmed that we were like-minded…at least as far as I could tell with the minimal involvement the customer wanted to take at that time.
Of course, in the end the only real solution is to fix the issue and move on, which is what I did. But I’m looking back and trying to figure out how I could have avoided that train wreck with some different corrective action during the requirements definition period. Since it’s an important, visible, and powerful internal customer, playing the blame game really does no good…it’s still all about customer satisfaction no matter who’s right.
Lessons Learned
If this were to occur in the future, and I was still unable to gain the proper involvement from the actual customer, I would likely request that they appoint an individual to work directly with me in detail on documenting and finalizing the exact requirements. That is my lessons learned from this situation. That way, the internal customer truly has better representation in the process because they will assign a dedicated individual whose job will be to ensure accuracy on the customer side. Whereas, in the situation I was involved with I had that responsibility as well as the delivery responsibility and the end result needed re-work before it fully met what the customer wanted.
Unfortunately, I unwittingly walked into one of those “I’ll know it when I see it” type customer situations that we all want to avoid. I find that those are much easier to avoid when the customer is external and knows up front that they are paying extra for everything not documented as a requirement.
RSS Feed
