Over the years, I have seen some pretty horrific enterprise projects, and they all had one common denominator.
I’m coming from Salesforce and SharePoint background, but the same problems exist in just about any case where an application has to be built based on requirements.
It’s the same scenario each and every time. Sales people work extremely hard to set meetings with senior management and the C-suite to better understand their technical needs and challenges.
After months of proposal preparation, slide decks, and meetings with senior management on both sides, a deal is now on the table, and the only part left is an approved statement of work (SOW). From the vendor’s prospective, this is great news and well deserved after all the hard work and time put into the opportunity. All the heavy lifting is done, and the vendor can go on to the next pursuit. From the client’s perspective, this opportunity will potentially solve a business need or problem, and this vendor is now considered their trusted advisor.
From the perspective of the architect, who was informed about the decision at the very end, it’s an uphill battle to understand what was said versus what is realistically possible while keeping both sides happy.
The architect’s responsibility is to put all the pieces together to come up with a solution that meets or exceeds the agreed-upon requirements. In most cases, this is quite a normal task, but in other cases, it is impossible. Here is why: the architect was not involved in the initial stages of the sale, and the vendor’s sales team oversold the software’s abilities to the client.
Some organizations have “technical” sales teams who are proficient in the art of sales and SPIN, but they lack the technical depth required to understand the client’s needs and meticulously map the need to the appropriate enterprise solution. The expectation is that everything will fall into place, and/or the architect will perform some magic to make it happen. Unfortunately this not how it works.
If the architect is included in the early stage of negotiations, he or she can advise the sales team on the risks associated with each approach. More importantly, the architect will advise if the opportunity is worth pursuing at all. Understandably, time is of the essence, and you don’t always have time to vet every opportunity, but even taking an architect with you to early-stage meetings will make a huge difference and save lots of backpedaling later. In CIO Straight Talk, Barry Libenson, CIO of Land O’ Lakes, puts it this way, “Anytime you have to go back to a contract [with a supplier] and start talking about terms and conditions that were negotiated a year ago, I mean, that’s a bad day.”
Another reason to involve an architect early into the project is that he or she can identify opportunities that may have been missed. An architect is always thinking about how everything will come together and asking questions (technical and/or functional) that help paint a picture of what the end solution will look like.
The excuse given by sales teams is “early sales meetings with the client are not technical and don’t go into the how.” All the same, the sooner you can have the “how” discussions, the better off you’ll be. Waiting until the very end, after the SOW/contract, is dangerous and only creates problems for the implementation team. By the time the SOW/contract is signed, the “how” and design should have been figured out.
In closing, before working on that enterprise application project that is going to revolutionize how the client does business today, think about the architect and implementation team that have to turn magic into reality.
Do you have a story about doomed enterprise project? Please share.