Agile Project Engagement Roadmap
(Parts of this posting were adapted from an email written by my business partner, Dale Kiefling)
We recently had the disconcerting experience of having a client cancel our engagement because they'd felt that we weren't being agile enough. In hindsight there were a number of reasons why this might have happened but I think the most important one was simply that we did not provide a clear overview of the engagement. This meant that the client was confused about the value of what we were doing. I myself am confused about how the situation arose. I thought we had been very clear but obviously that was not the case.
In our practice we typically combine a discovery phase and a prototyping analysis and design phase. What some people in the agile world might call iteration zero. For our client this discovery seemed open ended and they didn't have a clear understanding of how it fit into the project as a whole. This was a communication failure on our part. The process of discovery can indeed feel open-ended as it is the very nature of discovery to explore the domain of the business opportunity in an open way. The purpose of this "openness" is to find the appropriate scope, workflow, practical boundaries, and hidden benefits in an exploratory and visual manner.
The primary advantage of doing this work at a high level early on in the process is that it is much easier and cost-effective to identify boundaries and priorities on a whiteboard rather than during the construction phase or even during prototyping. We should have done a better job explaining this prior to our first discovering meeting which might have helped our client better understand our process and purpose. We also never really established a timeline beyond having one or more discovery meetings which may have added to their confusion.
Let's chalk this up to another lesson on the importance of managing client expectations.
We recently had the disconcerting experience of having a client cancel our engagement because they'd felt that we weren't being agile enough. In hindsight there were a number of reasons why this might have happened but I think the most important one was simply that we did not provide a clear overview of the engagement. This meant that the client was confused about the value of what we were doing. I myself am confused about how the situation arose. I thought we had been very clear but obviously that was not the case.
In our practice we typically combine a discovery phase and a prototyping analysis and design phase. What some people in the agile world might call iteration zero. For our client this discovery seemed open ended and they didn't have a clear understanding of how it fit into the project as a whole. This was a communication failure on our part. The process of discovery can indeed feel open-ended as it is the very nature of discovery to explore the domain of the business opportunity in an open way. The purpose of this "openness" is to find the appropriate scope, workflow, practical boundaries, and hidden benefits in an exploratory and visual manner.
The primary advantage of doing this work at a high level early on in the process is that it is much easier and cost-effective to identify boundaries and priorities on a whiteboard rather than during the construction phase or even during prototyping. We should have done a better job explaining this prior to our first discovering meeting which might have helped our client better understand our process and purpose. We also never really established a timeline beyond having one or more discovery meetings which may have added to their confusion.
Let's chalk this up to another lesson on the importance of managing client expectations.
posted by David Chilcott at 9:21 AM
1 Comments:
I have found that the reason a client "disengages" is usually because you were never engaged in the first place. There is a courtship period, where the client gets to know you. As in any relationship, it is far better to disengage early in the relationship. We have had a few engagements where we met once or twice and both sides realized that the relationship was not going to be successful.
We had one client engagement which proceeded beyond that phase and which ended poorly. When we dissect that one, it is clearly our fault. The client asked us to build a web-based product which perfectly fit our skill set, but wanted us to create an automated installation system for it which was outside our area of expertise. We explained this to them clearly (good) but took the project anyway when they insisted (bad). We completed the first part on time and under budget, but the installation system cost them more than they wanted, and we felt disgraced.
The point is that the client may have heard what you were saying, but did not understand the ramifications. Perhaps what is needed (I am guessing here) is a way to "quiz" the client -- ask them what they think the relationship/benefits/situation is, and see if it matches your own.
Keep up the good work, David.
Post a Comment
<< Home