I’ve recently begun studying for the PMI-ACP (Agile Certified Practitioner) exam with a small study group. Last week, we had our first meeting, and it has really made me reflect back on previous projects in which I’ve participated and see how we’ve applied Agile principles without calling them Agile.
As our study group was reviewing the 12 Agile principles, the following principle really hit close to home, “our highest priority if to satisfy the customer through early and continuous delivery of valuable software.”
As an IT administrator, developer, managed service desk lead, gone-back to developer, project manager, gone-back-a-second-time developer, and principal consultant, I have always found that if you satisfy your customers, you’ll be successful. That fact seems pretty straight forward and obvious, right? You’d think so; however, you would be amazed at how often (and easy) it can be to not satisfy your customer.
In the consulting world, we’re often faced with situations where for budgetary reasons, why we can implement a solution in the most efficient and scalable way. Sometimes, we’re charged with a brute force approach that “gets the job done” as fast as possible, albeit in a sloppy way. Many consultants will stand their ground insisting on not implementing a solution unless it’s their best-practice design.
Perhaps because I’m more passive and less confrontational, I prefer to take a different approach – I let the customer know their chosen implementation is not how I recommend to proceed and cite the examples. If they still wish to proceed disregarding my recommendations, I will document the recommendations, identifying potential side-effects, and proceed onwards. After all, it’s better to make progress and maintain positive communication with the customer than argue over unproductive details (see Agile’s “customer collaboration over contract negotiations”).
The soft-skill and incredibly difficult part of these interactions is the art of clearly communicating your professional recommendations while not alienating the customer. In these situations, I often take two approaches depending upon the customer’s excitement around their idea and proposed implementation. I’ve had varying success with both approaches, but my preferred response is, “Customer, I hadn’t considered that approach. Let me think about it and we can determine the best approach together once I’ve had a chance to digest it.” Now, I may already know there are several pitfalls to their approach, but if they’re really excited about their idea, then this gives us both a chance to walk away and come back with a fresh perspective.
The above approach works great when we have some time to make a decision, but when you need to make a decision immediately, you often need a more direct approach. In these circumstances, it’s important to validate the customer’s thoughts and opinions first, then lay out a clear reason why you feel it would be better to proceed otherwise. If you can drawn upon a past experience, and use that as a supporting reason for your recommendation, it can often pay off.
In a stalemate, is there an advantage to you staying your ground? Sure there is, you get to do what you feel is right; however, the time, energy, and drain on the relationship this negotiation may have probably isn’t worth it long-term. As a result, I tend to side with the customer. Even though they are paying me to be a trusted advisor, they are also paying me. If, as we move forward, there are issues with the implementation, we will have already discussed a perfectly acceptable alternative solution that we can re-evaluate and re-implement, if necessary.
What about those rare cases where you’re blamed for not “making” the customer see the correct solution you may have originally laid out? That’s even easier. Do you really want to be engaged with someone who is not playing by the same rules you are? Do yourself a favor – steer clear.
