Mock JADs Lead to Scope Validation

Client team members are often frustrated by expectations placed on them to review and approve deliverablesHow many times have you heard the following in reference to the client team members on your projects: “They just don’t get it!”

I’ve got news for you. It’s you who aren’t getting it. You do this for a living. They are on loan from their day jobs. If they’re not getting it, IT’S BECAUSE YOU’RE NOT GIVING IT!

Nowhere is this more obvious than during scope validation. I’ve seen hundreds of deliverable review comments from the client reviewers that were confusing or incorrect. I’ve seen scope added by reviewers that had never been discussed with the IT team.

I’ve seen clients so frustrated with their lack of understanding of the review process and the intent of the deliverable that they ask to go back to their regular jobs. I’ve seen them cry, get angry, walk out of meetings, and push back. These behaviors don’t bode well for project progress.

What is especially frustrating to me as an IT professional, is IT’s disrespect and condescension towards the client team members (not within their hearing of course):

“How could they not understand? – they’ve been in all the requirements sessions!”

“How many times do we have to explain the concept of decision tables to them?!!”

“It’s a Requirements Traceability Matrix! It’s not rocket science!”

“These are the rules THEY gave us! What do you mean they don’t understand them?”

It’s my contention that had the IT team done its job well, the client team would be able to excel at thoroughly reviewing the deliverables. This expectation by the IT team that it can toss the completed deliverable over the transom to client accolades and angel choruses is laughable.

Yet it persists. I’ve seen IT teams shocked – yes, shocked – that their painstakingly competed deliverables were returned with a myriad of review comments.

Kind of like getting a ‘D’ on a term paper.

On one of my more recent projects, I witnessed an optimal process to achieve quick and thorough deliverables acceptance. The IT provider and the PMO (of which I was part) collaborated on a method to create and review deliverables as seamlessly as possible. We started with the first major deliverable which was both large and complex, the Requirements Definition Document.

Rather than wait until we delivered 2,000 pages of requirements to the review team for its review and acceptance, we prepared for the eventual acceptance even before starting requirements collection. The first activity in our preparation was to assemble the Subject Matter Experts and other client team members to conduct “mock JADs.” That is, the IT team would lead a practice Joint Application Design (JAD) session with full participation of the client team members.

We selected an actual functional area for requirements analysis. It wasn’t long until the “mock” JAD became very real. We asked the Subject Matter Experts to take us into the policy manuals for clarification of rules. The team scribe took notes. An analyst filled up the whiteboard. The walls were papered with flip chart paper. We encouraged client staff to take markers in hand and correct what the IT analysts had written on the whiteboard. We started a “parking lot” for items that needed further research outside of the JAD session. We pointed client team members to the scope definition document to help them understand what was in scope for requirements and what was not. We even uncovered a risk event that was placed on the risk log and assigned ownership.

Why did we do this? Because we wanted the client team to understand the full process, end-to-end. We needed them to be fully bought in to the creation of the requirements deliverable. This would then translate into a more knowledgeable review and acceptance process.

Additionally, we invited client management to observe as we modeled the process for a functional area familiar to all. As we coached client staff in their actual roles, the management team began to understand what would be expected of them when we escalated items for their attention and resolution.

The extra care and attention paid off for the project. Not only did we meet our timelines, but the review and approval process was conducted smoothly. We had a solid requirements baseline approved by the client stakeholder. We had a team of client staff that was fully knowledgeable of their roles on the project. They were fully on board with the project scope.

And here is a bonus that we didn’t really plan for

The client team became so familiar with the project requirements and overall objectives, that they became a sounding board for the IT team during system design. I saw IT and client staff pull ad hoc meetings together daily to clarify detailed functional requirements for the design of system processes.

Naturally, that carried downstream to the development and testing tasks. The IT staff were confident that they were developing the new system correctly.

To me, it always comes down to the people aspects of project delivery. I have always found that the client team members are as bright and capable and engaged as the IT team members. They need care and patience as they learn new skills.

After all, they’re the experts. And it’s their system.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.