At times organisations need to embark on large information technology (IT) projects, replacing aging software or hardware, grabbing opportunities to create more efficient business operations or create a new revenue stream.  As a board member, governance group member, steering group member or leadership team member,  you will be expected to provide governance for technology projects.  In this post, we’ll give you 5 tips for technology project governance, to help you assess a project before it starts, and how to cut through the jargon and make sense of where an in-flight project might be.
It’s possible you have had little, none or bad experiences with such projects – or you might have heard some horror stories elsewhere about cost or timing blowouts.  You may have no practical knowledge of IT.  In this post our goal is to give you some tools and tips on how you might apply your own broad experience to the world of IT governance.  We want to help you as a someone charged with oversight of a project to understand enough to ask the right questions of your project team, and to enable you to understand the answers given.

Technology Project Governance 
It is often all too easy to wave off tech-speak and assume that because it sounds smart or modern, it is a good idea or the right thing to do.  In all industries there are several ways to do the same thing, each with varying impacts and risks – the very things every board member is expected to oversee.  How do you ensure you are meeting your fiduciary responsibilities and ensuring the best outcome for the companies you are charged to govern?

Before the implementation begins…
The organisation has assembled its project team, and they have been putting together their business case or project implementation plan.  They have presented this to your board for approval.  You may have confidence in the project team, or you may have never seen their work before.  Now you need to make a decision as to whether to go forward with the project.

Tip #1. It’s just another investment
Like any other time that you are making a large investment, it needs to be worthwhile.  It should have a clear return on investment, the risks of doing it or not doing it as they relate to the business should be articulated and understood, and the project team should be able to quantify what opportunities it presents to your business.  These opportunities may include increased efficiencies, reduced costs, increased revenue, provision of new services, and so on.  But whatever the opportunities, they should be clearly identified.
If the team presenting the IT project can’t quantify the benefits to be gained then it is worth probing further. Sometimes the driver is less of an opportunity and more in the nature of risk mitigation. Again that risk needs to be clearly qualified and quantified.  A risk like a “Burning Platform” is a good and valid reason to invest when it comes to IT.
Here are some questions to challenge you and your project team when considering a technology investment:

• Are the benefits targeted quantifiable? Do they align with your organisations business strategy and core purpose?
• Has the project team verified the problem they are trying to solve in a quantifiable way? Is there a problem?  Is it as big as everyone thinks it is?
• How does the project team plan to measure the value / success gained by the solution?
• Will sunk costs be recouped? Do they need to be recouped? What early check points are planned to assess if the ROI is becoming unobtainable? Similarly how will you ensure benefits targeted aren't being eroded by project compromises?
• What has the vendor done to ensure they understand the scope of the project / programme? Are you convinced they understand?  How has the project team assessed this understanding?
• Are the roles and responsibilities clearly split and documented between the different organisations involved in delivering the project and within the team?
• Who are the people involved and overseeing the project, what is their pedigree? A company may project a good track-record but that will count for little if they have put their newest recruit onto the project

Beware of the lowest price; too often project issues arise where the vendor has not fully understood the scale and scope of the work resulting in their quote being too low.

Project Approaches
Different projects will have different project management approaches. Installing hardware will typically require a “waterfall” approach (one stage followed by the next): detailed planning, architecture and costing followed by an implementation stage, testing and production release.
Another common project approach is “agile”.  The goal of “agile” is to bring those implementing the product and the final users closer, and it is becoming more common in the software world.  However, agile is also often done “wrong”, only parts of the approach are used or it is used as an excuse to avoid good software practice – such as missing good architectural planning, quality control elements or documentation of requirements. Sometimes a project will use parts of each methodology, but this should never be at the expense of capturing and recording requirements for the final product.
The key question for either methodology is: what will you get for the dollars invested?
Typically, agile iterates (regular releases of working software to users for live use) until the funding is done or the necessary functionality is in the software.  Functionality is prioritised by users so that the functions important to them are delivered first;  Possibly identifying functionality that wasn't originally considered but in real world use found to be necessary.  Possibly finding planned functionality isn't necessary.
However, this approach does run the risk that not all the necessary functionality will be implemented as part of the delivery due to running short on funding.
This approach also poses problems when engaging a vendor to do the work for you, as the vendor often cannot commit to delivering a whole functional set within the budget and / or timeframes. This then requires a great deal of trust that both your users and the vendor understands what they are trying to deliver before the work starts.
In theory, the waterfall methodology, can cost out the project from start to end, but it has been well documented that this process also often fails or requires changes to the projects functional deliverables, timelines or quality in order to “complete”.
You can just as easily end up with the same problems as agile if scope and technical difficultly aren't understood when planning a waterfall project. In some cases it is not possible to understand the technical ins and outs of project at the start. In this case you might consider agile and controlled tranches of work with clear assessment of benefits gained and to be gained on completion of each tranche.  You may not be able to get that guarantee on return on investment.
Neither methodology is always right or wrong, but each is more suited to different project types and the risks you are willing to take.  Both methods require strong scope control, ensuring the area of the project most important to the business it kept in-check by managing that aspect; time, cost and functionality implemented (scope).
So think – waterfall or agile? Are you comfortable with the implications, trade-offs and risks inherent in the methodology selected by the project team?
If you want a great run down on agile v waterfall I recommend Max Bondorovsky's linkedin post "Agile Vs Waterfall. Methodology arguments must stop."

Tip #2. What are you buying and who are you buying it from?All too often an IT system is seen as the whole solution to a problem, more often than not it is only part of the solution that also requires people and process changes in order to gain the benefit - in systems if you put garbage in, you get garbage out.
Technology investment should be about the outcomes you are trying to achieve... the “what” you buy to achieve those outcomes will vary.
Say for example, you might want to improve customer engagement.  You could do this  by implementing a new customer portal and customer relationship management (CRM) system or you could put in a process where you hire PA to take some admin tasks from account managers so that they can visit clients more often.   That last one isn’t a technology solution but may still achieve your goals without the disruption of introducing a new IT system – non-IT options can be as effective as introducing or upgrading the IT solution, it all depends on the return on investment of the possible solutions.

Off the shelf vs build
When looking to implement a software solution the typical options presented by software vendors are; an “off-the-shelf” solution that is configured to meet your requirements or a "bespoke software" build where the software is created to meet your needs specifically.
There will be several factors that the project team should have considered when they were looking to choose a suitable solution, including; how much configuration is required to meet your needs, how unique your needs are, what commercial advantage you are trying to gain from the solution, your budget constraints, and whether “off-the-shelf” actually exists for your organisations specific needs.  The big assumption here is your team know what your "needs" are!

Which vendor?
Local, small, big, national, international?  There are a myriad of configurations in the who to do the work for you.  Is that 2 person development shop going to be able to get through all the work, can they support you well enough afterward?  Will you just be a small fish to a large national or international IT company, therefore not getting the attention you need because there are more important people (big fish) on their list of clients?  Do they have mature support and maintenance processes?
Committed people and strong communicators are always the key to good project outcomes, no matter the What (COTS or Bespoke) or the Who (which company).  Once the project is done it is the processes that are left in place and the commitment of your organisation to continue with the software that will see benefit realisation.

Multi-nationals
You may be considering an international company, however, going to a large international company may only result in international costs.  New Zealand IT company's are on the forefront of many innovations so looking beyond our borders isn't always necessary.  It is also worth considering whether potential cultural and language barriers will slow things down.  As well as this, consideration of the ongoing support you seek / need for your final product is key; how are they currently equipped? how have they performed in the past?  If these and the questions below are addressed then it may be a very sound move.
In order to ensure you know what you are buying and from whom, you might ask the following of your project team:

• What evidence did the vendor provide for creating the value / benefits targeted by your project when they implemented their solution elsewhere?
• If it is the first time the vendor is implementing this product Or it is bespoke, do they have a track record of creating the targeted value with other products or projects they have completed?
• How have the vendors established the functionality required and how have you ensured they understand the scale of the business’s needs?
• COTS: What is the percentage of configuration versus development? (it would be worth making this a metric in your ongoing reporting - specific development done to an off the shelf product will often create maintenance issues down the track)
• Have the vendors developed software of this scale before (remembering there is scale of deployment versus scale / complexity of the system build itself)?
• Who will own the final product? Who will own any intellectual property (IP) created as a result of developing your product?
• Has the team done a thorough background check on the vendor?  Does their delivery match their sales pitch?
• Does the vendor follow good software development processes and practices?

Project implementation has begun…
​So, the project is signed off, the teams seem to be operating according the plans you have signed off earlier.  Now you want to know that the project / programme is on track and you aren’t going to get 80% through the time and find that you are only 20% through implementing the tool or worst yet not on target to create the benefits you need to see created with the budget you set out.

Tip #3. How to know if it’s on track
It is important that you ensure the project / programme team have suitable controls in place to track the completion of the IT project and to help identify when the project / programme is about to go off track (or already has).
On Track / off track
The dimensions of “on track” are broader than simply completing scheduled tasks until the project is done; your team may be completing scheduled tasks but if the releases of the software aren’t delivering the functionality required, or the quality of the output is poor, or there are interim measures going into the system that must be unpicked later then it might still be “on schedule”, but it is definitely not “on track”.
Much of "on track" is also about future gazing, looking at the trends in the measures you have, the checkpoints you have in place, and extrapolating what might happen - risk assessment.  Things like; Given the rate of burn on budget vs functionality delivery, are they going to complete all the work in the dollars allowed?  Is that unexpected technical hurdle you hit going to suck all of the resources away and delay the other parallel works?  Sometimes your measures of on track / off track might look generally alright, however that slight hiccup may be showing that its on the way to being well off track if action isn't taken soon.
When checking your teams understanding of how on track their project is, ask things like:

• Can the vendor and project team demonstrate that milestone dates are based on logical review of the work to be done or are they arbitrary and driven by a need to complete something by a certain date?
• Are tasks being completed?
• Is functionality being delivered in the timeline expected?
• If the schedule is elongating from its original plan, will your budget support the longer time frames?
• Is delivery versus budget lining up?  If you are using tranches are outcomes matching with the spend?  Is the vendors billing restricted to payment on delivery, rather than Time & Material (T&M)? If its T&M, is their burn rate matching their delivery of outputs?  Are they going to come back looking for more when your at 70% completion and "can't turn back"?
• Is the scope varying – additional things being added that weren’t included in the original thinking and not being traded for increase of cost, increase in time, reduction of quality or reduction in functionality?
• Is the way the functionality is being implemented going to create the benefits and the return on investment targeted by the project? If your team measured the issue before hand they will be able to provide an informed view of likely impact on the issue, if it is agile you should be seeing some of these things dealt with in earlier releases.
• Rather than "are x% tasks complete" try "are x% functions complete" and will they create the value you need?
• Are risks being managed? Is their likelihood or impact increasing? (is this being measured?)
• Are important phases being dropped to meet timelines (e.g. reduced time to test / verify in order to meet dates, attempting to go live at the expense of testing, rushing to build without suitable foundational architecture)?

In order to get answers to these questions there will need to be mechanisms built into the project management.  Regular stage gates that assess quality and completion, reporting on progress  against functionality completion, budget used, risk and issue logs that demonstrate they have been updated regularly (as well as discussion of risks and issues with you that need your support).  If these aren't in place and the programme is underway I strongly suggest you get them in, in the meantime listen to the concerns raised from the wider project team, if senior IT staff or users are raising concerns address them.  We'll cover more of that in a future post about ways to identify a project that is in trouble.

Tip #4. Change Management, Change Management, Change Management!
Often the hardest part of a project is managing the change it introduces.  It is on change management that the project’s success hinges, without planned and deliberate management of change your wonderful new IT solution will not work in your organisation.  For example, if you introduce a new mobile solution for staff to use in the field, but don’t manage the change around the effect on day-to-day processes for your staff (training, demonstrating value to those same people) and allow for the initial disruption, you will see a much longer time before you get that return on investment.  If things go particularly wrong you wont see any return on investment if the solution is not accepted by the organisation.
Our experience has found that planning the change at the start of the project, then engaging those affected by the change during the development and deployment brings about the best adoption and ownership by staff.  As such, change management starts at the beginning of the project.  It’s not the final act, it’s an ongoing stream of work throughout the project / programme that intersects and is supported by the development and implementation phase.
Not all change affects just your organisation, sometimes the change you are creating will be wider and broader than those boundaries.  To this end, the change management programme needs to be geared to cover other groups too.
So, how can you assess change management? Firstly, ensure there is a change management programme included in the project plan(s).  Secondly you need to consider how you can clear blockages and support efforts to enable the change to occur, expect your project team to present these opportunities to you as part of their planning.
To help you assess the effectiveness of the change management for the project that you are overseeing you might ask:

• Does the change management plan use a mode like ADKAR?
• Does the change management plan consider all affected parties inside and outside your organisation?
• Have they identified the affected parties motivations to engage with the changes being introduced?  Are the affected parties being motivated to use the new system or engage in the new process?
• Ask regularly throughout the project; what is the progress on the change management programme?
• Has the evaluation of the solution at its various stages included feedback from the affected users?
• Is your organisation geared for change, does the plan take this into consideration?

If you are looking to create a change culture around LEAN processes you might consider contacting somewhere like IMS Partners.

Tip #5. Celebrate and Evaluate!
​The implementation part of the project is done! The system is in, there is still the ongoing change management programme to complete.  The solution needs to be evaluated, the ability to measure the impact of the change could be instant or may take some time to get to the point that it is measurable.  A lot of people have likely worked very hard to get the project to this point.  It is time to recognise all the people that have made it happen (that includes you)!
Celebrating key milestones is simply part of good HR.  Ensuring your business is reflecting back to the project staff their value is a worthwhile investment to make in order to keep them with you - remember most of them now have in-depth knowledge of the solution you just introduced.  Most “top 10” lists of why people stay or leave their job include employees feeling recognised and appreciated by the people in leadership positions, this is a great opportunity to reflect that.
Ensuring you get a returnAt the beginning of the project the business case or project implementation plan described benefits that were targeted by the new system.  Too often the end of the implementation sees all that intent to justify the investment evaporate.  The money is spent, you can’t get it back, it seems to be working, why bother now?  However the evaluation achieves two things:

1. Validates (or invalidates) your justification for the project in the first place
2. Identifies where further investment might be directed to fine tune the solution

Validation / invalidation will help inform future investments; did the vendor perform well?  If we had to invest in another part of the business would it work? what would have to be done differently to make it work?  What would we test in the next proposal to avoid the same mistake(s)?  Did we exceed our expectations, were there unexpected benefits that can be qualified?  How can the next project be done more efficiently?  Your vendor should be thinking the same things; what would they change in the way they did things to make the next project more efficient?
As a consequential bonus, if you are involved in more than one board the lessons learnt from one place will be invaluable in the next and help in avoiding the same mistakes.  It also lets you assess the different methodologies; what worked in this organisation, what didn’t.  This will likely arm you with better questions to ask of the next project.
Ongoing investment
Most IT systems are not static.  They are living systems that need to change and adapt to your business and their own environment.  More often than not, once a system is installed there will be learnings as to the better way to do things.  Evaluation results will point to where issues remain or opportunities lie for other uses of the system.  As an IT system becomes embedded in your organisation systems and processes, this means changes to the system will create more benefits and advantages to the business.  To this end it is worth ensuring there is suitable ongoing business as usual management and funding to support necessary improvements.
Questions you might ask at this point are:

• What’s the process for getting those changes justified, approved, and signed off?
• Where is the funding in the budgets for this?
• What sort of agreements are in place with the vendor for supporting and enhancing the solution?
• How are you controlling change requests?
• What sort of change control process are in so that new features or bug fixes made by the vendor don't unduly disrupt your new processes?

There is mountains of advice on change control and service management.  Resolution8 can support you in setting up contracts and management of those, however using an organisation like Gander Service Management to support your IT team in getting their change process right would be well worth the investment.

Finish
This post has, very lightly, touched on several areas for you to consider around technology project governance.  Hopefully you can use the questions and understanding here to gain further confidence your decision-making process.
We at Resolution8 are always available to help you assess your planned project, help you bring them back on track or get involved in helping you shape your planning around using technology to solve a problem.  We are independent of the IT vendors in the market and so our only motivation is to understand your business, your needs and ensure these are met by the technology vendors engaged to deliver your technology projects.
If you want help with your next IT project, need to getting one on track or just need another set of eyes on that latest proposal from IT contact Peter Gilbert. 
Our next series will review common signs that your technology project is in trouble and what you can do about it.