Today’s entry I wanted to focus on a tactical, down-in-the-trenches topic that several of my colleagues and I have bantered around when we discuss good and bad project methodologies. It’s on how to get the client to”really” accept the project.
I’m sure most of you have been on countless projects where each time the project has moved on to a critical milestone in its lifecycle, you’ve encountered a “roadblock” because of a series of minor defects or project “concerns” which tend to be non-critical or perhaps beyond the scope of the project altogether. As a result, the project just can’t move over the “finish line”.
Most recently, I was on a project where we were in the final phase of delivery. All the code had been written, unit tests and regression tests had been completed and the final milestone for final user acceptance was near.
What came back after a first round of testing were a series of identified problems, none of which were “show stopping”. Then a few more and then finally a a notice that the customer/client deemed that UAT could not continue and we had to re baseline our project goals.
Some of them were simple to diagnose and fix; some of them were due to an incomplete and vague spec delivered to the team; some of them were feature requests for new functionality. So how does one manage these kinds of setbacks/obstacles in trying to move a project forward?
Well, there is no magic bullet that will solve this problem in all and every instance. What my team utilized was a series of principles we identified to drill down into actionable items to manage the process in more reasonable chunks. At the core we found that following general principles helped in our delivery:
Communication
Clients and stakeholders value the immediate raising of issues before it becomes too late. No one likes surprises but how such a simple principle gets lost in translation.
Let me give you an example, after our version 0.9 of what I call our “customer engagement model” we decided to look internally at what was causing the confusion and delay and discovered that our engagement criteria with our client was just too ambiguous. After this realizaton, we found that we needed a better communication model and worked with our stakeholders on doing a better job of communicating problems earlier and more frequently.
We revisited our User acceptance Criteria document to better identify how to interact more efficiently on issues. From this we developed a point scale
to categorize and rank our defects with an agreed upon high water mark on what were necessary tests defects that warranted scrutiny and what could be put to the wayside.
Our weekly acceptance and review meetings became daily stand ups where our stakeholders can come and review the progress being made on our efforts. We posted all the defects on the board and showed the progress of movement using a Kanban like defect tracking system where defects can be seen and earmarked as complete when our developers completed known issues.
Specifics and Details
In Walter Isaacson’s book about Steve Jobs a very interesting scene between Jobs and his advertising company had transpired where Jobs was unhappy with the progress of the iPad commercials. The final distillation was a shouting match between the firm and Jobs where the advertising firm threw their hands in disgust and said “TELL ME WHAT YOU WANT!” In that instance, I think Jobs suffered from a “I know it when I see it” syndrome. I’m sure we’ve been in that situation where the client assumes we know what they want.
In our case, we discovered that our problem was that the subject matter expert didn’t know how to explain what they wanted for fear that their jobs would be replaced.
Our answer was to sit down with the subject matter expert and go through the workflows. We prepared screenshots, user state diagrams, business cases and scenarios where each was a story board. We had to collaborate with our client in much the same way a tailor would work with you for the right fit in your clothes. The close interaction always will warrant discussion.
Change is an inevitable but scary thing. We approached the problem much more interactively by clarifying needs, wants and goals so that we could collaboratively work towards the end goal. This brought about a much less confrontational atmosphere while allowing us to focus on productivity without having to worry about large, out-of-our hands organizational changes. We just decided that we were all in it together.
Accountability
One of the revisions in our User Acceptance criteria documents was “Department X will test this”. This is one of those retorts that was way to open for interpretation. We received many of these types of responses. To deal with this we had to push right back and ask for DETAILED clarification on the parameters on how this would manifest itself.
We needed further clarity on WHO would test it? HOW they would test it with mini-milestones and tasks for the testing criteria. The Use cases and the scenarios for that testing.
The WHO was the critical component. The expectation on the receiver of the deliverable was that the development team would be the ones to perform X. We needed more accountability than that by identifying the specifics of the testing criteria.
Teamwork and Incentives
When I hear terms like this and read about others on project management jobs, I often wonder what makes their projects work better than mine and whether this is all just lip service. Teamwork is one of those overused and under appreciated terms in any project that I’ve been on. It’s sort of like the elephant in the room. It’s there but nobody wants to do anything about it. If you watch the two teams during the Superbowl you can really see how the orchestration of teamwork is why we project managers often use the term. Unfortunately, in our world the means to the goals are quite different as well as the incentives that go along with it.
Creating incentives is probably the only way to cause fractured groups to work together. Let me give you an example.
On the subject matter side, we had to identify what was causing the constant fracturing between the teams and after many meetings with our stakeholders, it became apparent to me that the driving incentive barring adoption of our solution was the fact that the solution could spell the beginning of a shift in change that often leads to job reduction. Immediately, we needed to introduce a better communication model with our stakeholders to show them mutual benefits of adopting the system. We also started to involve more senior management and program management constituents to create the necessary transparency framework for clearer communication of what the change meant.
On a more tactical level, we started to take processes and started to gradually introduce them into workshops so that the user could see first hand how the change would work for them. I’ve heard terms like Waterfall methodology and Agile Development. These are all methods to help you organize and they are also dated to their technologies. We utilized a waterfall process which didn’t suit well for a constantly changing environment. Introducing and adapting to an iterative model (some may call this Agile or XP) helped us to interact more closely with our users.
These workshops were a precursor to UAT training and may have gone against some PMP principles but we discovered that a close interaction framework with users was better suited. It also helped to create the incentive that the newly introduced process made their time more valuable for them to focus on more strategic issues.
Next time when you are working on your project, think carefully about defining a better recipe for engagement and bring your own framework to the table so that you can better manage the process.
