Note: This is the 4th article a 4 part series. You can read part 1 here.
One of the core focuses of our business is maintaining the consult, design, implement and support lifecycle in order to deliver the best possible outcome for both our clients and ourselves. In previous blog posts, we’ve discussed the consulting, designing and implementation stages of the proof-of-concept (PoC), and how “when they’re done right“ they can facilitate business objectives, reduce risk, and reduce the amount of time it takes for a business to get some value out of the solution.
But what happens once the agreed solution has been put in place? Does it run itself, and meet all requirements, with no additional input from any involved parties? In an ideal world, sure. But the sad truth is that no matter how well designed a solution to a problem is, some things won’t go as expected. Anyone that’s ever had any involvement with project management will understand this. Objectives will not have been sufficiently defined, or communicated. Something will break, or take longer than could be reasonably expected. A good project manager will understand this, and account for it in deadlines. A great project manager will understand this, account for it, and have support structures in place to identify issues before they have any impact, or failing that, to resolve them as soon as possible.
Communication
This was one of the deciding factors in the success of our recent PoC. Given that we had unclear initial requirements, keeping an open line of communication with the ISV requiring the PoC for their client was critical. In this case, we broke the mould of our normal service model engagement and used Skype group conversations for use as war rooms. This provided three organisations, spread across four continents, a central location to discuss and address any additional requirements or issues on-the-fly. Tight timelines combined with disparate time zones meant we were working around the clock at times this model allowed each organisation to swap out resources whilst still ensuring chat history was accessible to all, keeping everyone on the same page.
Flexibility
One of the challenges we faced was the lack of administrative access to the underlying virtual machines on the infrastructure that we’d stood up, as much of the code for the PoC was being compiled on the fly. This made it difficult to troubleshoot and manage performance issues, but by working closely with the ISV (read: communicating!), we were able to address these problems in a timely manner. While this is not a typical situation, we were able to adapt to the customer’s requirements and still deliver the right solution.
Agility
While we’d like to say everything went according to plan, it unfortunately did not as is often the case, there were road bumps along the way which we were able to resolve quickly. One of the HBAs on the storage device was dead on arrival, and needed to be swapped out before the PoC could continue. This was resolved in a day. When it came time to return the equipment to our vendors, the bank data needed to be securely wiped. This was initially estimated at 72 hours, but climbed to over 110 hours. Â In order to meet our deadlines, one of our team drove out to the data centre over the weekend to hand-deliver the equipment back to our vendors.
At the end of the day, the solution provided exceeded all expectations because of our strong belief in getting it right the first time, and maintaining it to ensure that it stays that way.
Wanting to run your own proof of concept? Contact us to discuss how Starboard IT can help you deliver a successful business outcome.
