Menu
The cutting edge conundrum

The cutting edge conundrum

Innovation is an inherently risky place to be, more so when you are depending on a vendor for the project. Here are some critical steps to help you reduce the risk and raise the chances for your project success.

“We want to stay on the cutting edge of our industry.” You hear that a lot in business circles, especially in IT, because we thrive on innovation … that is what IT brings to the table. It is much more exciting to describe what you do as Leading Edge, Bleeding Edge, Cutting Edge – I guess we all just love to be “Edgy”. (Besides, that “edginess” justifies our right to come to work in jeans and tee-shirts because “we’re just that cool!”) But one of the challenges that IT departments face (besides “which Huffer Tee looks the best with my knit scarf?”), when pioneering innovative solutions for your organisation, is that often potential vendors will respond to an RFP and due diligence activities without an existing product against which to conduct traditional gap-fit analysis. But what does due diligence look like when so much is unknown? How can you increase the likelihood of success while pioneering into the land of “never been done before”?

As one who has been around IT projects for the better part of 15 years, I have seen development projects go well and go badly.

Innovation occurs by venturing into the unknown, the new, the never done before. This is an inherently risky place to be. Adding a development vendor could add to the risk. Here are a few suggestions on how you can enhance the success of your vendor development project:

Remember that you are buying a service, not a product – When engaging a vendor to develop a product, we must recognise that we are not buying a product, but rather a software development service. Particular attention should be paid to the vendor’s track record of successful innovation with other clients. How well did they understand the client’s ideas and translate them into a tangible product that met their expectations? How well did they manage the relationship? Just because they developed a good Commercial Off-the- Shelf (COTS) product several years ago, does not necessarily mean that they can innovate with new technologies or deliver other people’s vision.

Don’t over-customise an established product – Conversely, if you select a product because it is stable and in use at other organisations, but then require significant customisation as part of the implementation; the advantage of selecting an established product will be lost. It may be more advantageous to accept the functionality as delivered, and keep customisations to a minimum.

Have your own Technical Lead – A client-side senior development manager, solution architect, test manager, infrastructure architect and so on, can be very helpful by representing the client’s interests when dealing with a software development vendor. They will provide technical expertise to the project team, and auditing of vendor processes (below).

Technical due diligence and ongoing process audits – Most Request for Proposals (RFP) are “stock standard” procurement and legal processes (and often times done in a hurry. They ask the same questions regardless of if they are looking at a new Enterprise Resource Planning system or arranging a new supplier of office supplies. On a similar note, contractual incentives and penalties (that are often the focus of conversations) set the boundaries in which the engagement operates, but are by no means a guarantee of project success. (Besides, later down the track, if you start referring to the vendor’s obligations in the contract – this will usually put them in legal defence mode. They will be more worried about how their response will look in litigation, rather than how to deliver the benefit that you need to make the engagement successful). When you are looking at selecting an IT product, or development vendor to help you create it, there should be a technical due diligence exercise as well. This should occur on two levels:

A technical review of the product – many RFPs include a functional gap-fit analysis exercise – is important. However, a technical review of the product that investigates the solution design, architecture on which it is based, how it interfaces with your current systems, and how well it aligns with your organisations IT infrastructure, will also save you a lot of frustrations and expense down the track.

A technical review of their development and quality assurance practices – For those larger engagements where a vendor will be responsible for developing a custom application, you should also conduct a review of their development and quality assurance practices. Certifications such as Capability Maturity Model, ISO, and others only verify an organisation had a documented process at the stage they achieved certification. It is not a guarantee they currently adhere to these high standards, or will continue to do so when the deadline pressure is on.

Conduct periodic on-site audits by your own technical expert of the vendor’s software development and quality assurance processes — Include termination clauses in the contract in case they fail your quality audits at any time during the project. Key areas for technical due diligence and audit should include:

• technical documentation review

• solution architecture

• data model

• infrastructure architecture

• software development processes

• quality assurance processes.

If the vendor refuses to provide such documents (perhaps claiming intellectual property, confidentiality and so on) it is more likely that these documents do not exist, or they know that the quality of their documentation reflects a poor standard that they do not want you to see. Whenever a vendor refuses to provide such information (although non-disclosure agreements or objective third-party reviews are offered) I start seeing red flags waving!

Quality Gates and Deliverables (with termination clauses) through the life of the project – In long-term development projects, a client needs the ability gauge vendor performance through the life of the project and “cut their losses” as early as possible. (This is where an iterative approach — insert your favourite flavour of Agile here — would be the best bet – but that is an article for another day) Payment schedule and quality gates should be tied to delivery of tangible outcomes and business value rather than project phases.

Schedule a significant delivery early in the project. The sooner you get tangible outputs from your vendor, the sooner you will know their ability to meet deadlines and your expectations of quality and completeness. Early deliverables are the canary in the coal mine for future milestones. Until the vendor actually delivers something, I consider them an “unknown quantity” and their ability to meet schedule and quality a risk to the project.

Conduct Lessons Learned reviews during the project and adapt accordingly (rather than just at the end) – Conducting lessons learned exercises during the project enables the team to identify what is not working well at that point. Timely adaption as a response to any identified issues enables corrective actions to occur and enhances the likelihood of a successful outcome. This is a feature of Agile projects where regular Retrospectives are a common feature.

Shared Risk / Shared Reward – Joint green-fields development engagements should be structured such that the vendor shares the risk of failure and reward for delivery. This can include enabling the vendor to on-sell the product after a set number of months (giving you as the client a first to market advantage, while giving the vendor a proven product to sell).

For larger projects, client-side representation should extend beyond just the project manager to include contract management, performance management, and relationship management expertise. Many vendors have several people working on a single account. Ideally, there should be a one-to-one relationship between the vendor representative and their client counterpart.

Break key phases into separate contacts – By breaking key phases into their own contracts, the vendor is responsible for completion of the phase (and the quality of the outputs), and your company can have better visibility of pricing (whether the initial “cheap deal” on development will have repercussions on BAU support pricing). An example of this would be three separate contracts with the vendor for 1) Design and Planning, 2) Development and Configuration, and 3) BAU support.

Adapt project management and development approaches to current reality - In the event that you start a COTS implementation, and it turns into a product development venture, it may pay to adapt the project approach to account for change in the development situation. Also, if it is a known green-fields development effort, you may be able to influence the vendor engagement to include an agile development approach, co-location, along with shared risk and reward.

Chris Pope has spent the past 15 years combining project management and business leadership expertise with a pragmatic approach to rescue projects and business units in crisis, manage complex enterprise-wide programmes, and streamlined business processes. He has worked in industries including Airline, Management Consulting, Local Government, Healthcare, Telecom, Internet, and Non-Profit. He currently manages a PMO and often speaks on various business leadership and project management topics. You can find him on Linkedin at http://nz.linkedin.com/in/chrispopepmp

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags Air New Zealandchris pope

Show Comments