Technology Vendor Contracting: Breaking the Mould

By Timothy Nuckles

Commercial buyers of information technology products and services are locked into a self-defeating pattern of behaviour when it comes to negotiating contract terms and conditions with technology vendors, and it is time to move on to a better approach. Better technology vendor negotiations produce better contracts for a technology project, and better contracts produce better project outcomes. So, break the mould and move on to a better way of negotiating contract terms and conditions for your next technology project.

Vendor Contracts - Timing Is Everything

Let us assume that by now you have done a lot of planning and information gathering for your proposed technology project, you have completed a vendor selection process, and now it is time to document your deal with your chosen vendor.

At this stage in the technology procurement process, the most common practice, indeed the almost-universal practice, is to distribute the vendor's proposed contracts to your project team for review and comment. Then, as if by instinct, everyone starts looking for vendor bias in the contracts. No one has been given this specific directive. You simply assume and expect that everyone knows the drill. Folks on your project team begin striking certain biased provisions and scribbling notes about amending others. For sure, removing or limiting vendor bias in the contracts is a worthwhile exercise, but now is not the time to perform this exercise.

Light Bulb On

I had to get several technology deals under my belt before I realised this, but at this early stage of the contracting process, you really need to focus first on terms and conditions that are important to you, not the terms and conditions that are important to your vendor. We know your vendor has included in its specimen contracts (as modified prior to presentation to you) all the terms and conditions of your deal that are important to your vendor. In fact, they are very easy to identify. They are all the contract terms with vendor bias. These provisions are so important to your vendor that it has purposely added bias to them, often with obvious exaggeration and redundancy. Even if your vendor has to bargain down somewhat from these provisions, your vendor is still in a safe position because the starting point was so extreme.

What You Should Do Instead

At this initial stage of contracting, you should ignore your vendor's proposed contracts. Simply set them aside for the time being, and do this for two reasons. First, in order to express in writing the terms and conditions that are most important to you, you must actually think of what those terms and conditions might be. Likeable as your vendor may be, your vendor will not have already added to its proposed contracts the terms and conditions most important to you for your particular project. You will have to come up with this stuff on your own.

Second, until you know what terms and conditions are most important to you for your particular project, you are in no position to challenge your vendor's biased provisions except in attempt to remove or limit the bias. "I don't know exactly what impact this provision has on our project, but I know it's not a provision that helps our cause." Challenging these provisions in a vacuum does not really help you.

The Big Picture

Now is the time to start with a fresh, big-picture perspective, and then fill in lots of detail. Circle back to earlier stages of your procurement process and revisit your decisions, your assumptions, and the various things you have learned. As a result of your many meetings and discussions, there may be things that you are now taking for granted: special vendor qualifications, how a particular piece of your project will be orchestrated, acutely risky aspects of your project, and so on. Bring to mind other similar projects within your organisation and apply what you learned from those experiences.

Re-acquainting yourself with prior thought processes, discoveries, assumptions, and experiences will help you remember aspects of your project that you previously deemed important, whether because they are critical to project success, they pose a substantial risk within your project, or perhaps both, and it will force you to consider the importance of other elements for the first time. This process will help you build out the terms and conditions for your deal that benefit and protect you, terms and conditions that maximise the probability of project success and minimise project risk.

As part of this process, make a detailed list of terms and conditions that are important for your particular project, and:

1. Categorise them by subject matter.

For example, requirements development and prioritisation, data mapping, business process issues, software development, application integration, database integration, system integration, testing, implementation, buyer protections, vendor management tools, warranties, etc. When you get around to negotiating the items on your list with your vendor, your project team will have important reference points. "Does this contract item touch implementation? If so, let's look at our implementation items."

2. Add qualifiers for each item.

Among other things, qualifiers can include a ranking of particular item's relative importance within your project (critical to project success, represents substantial risk, wish list, etc.). When you get around to negotiating the items on your list with your vendor, your project team will be less inclined to treat all items on your list as equally important. Almost certainly, not all will be equally important. Your team will have a sense of how hard to push on a particular item, and in terms of the give and take that occurs in any negotiation process, they will have sense of what items to compromise (and by how much) or concede outright if met by strong resistance from your vendor.

3. Add relevant notes and comments for each item.

Among other things, relevant notes to attach to your list items include comments about accountability. Who within your project will be accountable for accomplishing the particular item: your vendor, your internal staff, or some combination? And what should happen if the party with accountability drops the ball?

With this kind of list in hand, you are in a much better position to review your vendor's proposed contracts. Perhaps most important, you are no longer reviewing the contracts in a vacuum. You are equipped to conduct a truly meaningful review of your vendor's proposed contracts.

Is there a gap in the vendor's proposed contracts; that is, an item from your list has not been addressed at all? Is there an inaccuracy in the vendor's proposed contracts; that is, an item is addressed, but its present treatment does not match your understanding, preference or requirement? Are topics within the contracts miscategorised? Are interrelated items not treated as such? Are accountabilities not clearly established?

An Even Better Approach

Although breaking the mould and adopting the above approach to technology vendor contracting will certainly help you produce better contracts for your next technology project, which contracts should facilitate a better project outcome, there is a way to help yourself even further.

Instead of starting with and working from your vendors' proposed contracts for your next project, think about developing your own standard agreements to include within your technology procurement process (usually at the RFP stage). First, develop a neutral or somewhat buyer-favourable Software License Agreement. Find a standard Software License Agreement and neutralise or remove the elements of vendor bias. Then add the buyer-side content that you would normally find yourself negotiating with a typical vendor (were you working from the vendor's standard Software License Agreement). Next, find a standard Consulting Services Agreement and do the same thing.

You can add your newly-developed standard agreements to your next technology RFP and request that responding vendors either approve your standard agreements as-is, or cite alternative language for provisions they do not find acceptable.

By incorporating your standard agreements into your technology procurement process, you will achieve two important things. First, you will be able, probably for the first time, to evaluate vendor candidates based on one of the most important factors for project success, terms and conditions. You can guage a prospective vendors appetite for terms and conditions that are important to your for your particular project BEFORE you have selected a vendor. It is much harder to win favourable terms and conditions AFTER you have selected the vendor for your project. And second, you will greatly reduce negotiation cycle times.

More and more commercial information technology buyers, of all sizes, are using this approach. It may surprise you to learn that many reputable technology vendors will not only entertain the possibility of working from your standard agreements instead of theirs, they may even welcome the prospect because it saves them time and expense as well.

A Word of Caution

When you develop your own standard agreements, exercise some discipline. Do not convert a terribly vendor-biased agreement into a terribly buyer-biased agreement. This will not help your cause. Instead, shoot for balance. Software developers, for example, are entitled to and must protect their rights in their intellectual property, and there are certain limits beyond which they will not venture; for example, an excessively broad licence grant. Understand vendor limitations and be fair. Add buyer bias judiciously and only if it is truly important to your organisation.

The Purpose of Project Management and Setting Objectives

By Brian Miller

Project Management has developed in order to plan, co-ordinate and control the complex and diverse activities of modern industrial and commercial projects. All projects share one common characteristic - the projection of ideas and activities into new endeavours.

The purpose of project management is to foresee or predict as many dangers and problems as possible; and to plan, organise and control activities so that the project is completed as successfully as possible in spite of all the risks. The ever-present element of risk and uncertainty means that events and tasks leading to completion can never be foretold with absolute accuracy. For some complex or advanced projects, even the possibility of successful completion might be of serious doubt.

Project management can involve the following activities: planning - deciding what is to be done; organising - making arrangements; staffing - selecting the right people for the job; directing - giving instructions; monitoring - checking on progress; controlling - taking action to remedy hold ups; innovation - coming up with new solutions; representing - liaising with users.

Setting Objectives

Effective objectives in project management are specific. A specific objective increases the chances of leading to a specific outcome. Therefore objectives shouldn't be vague, such as "to improve customer relations," because they are not measurable. Objectives should show how successful a project has been, for example "to reduce customer complaints by 50%" would be a good objective. The measure can be, in some cases, a simple yes or no answer, for example, "did we reduce the number of customer complaints by 50%?"

While there may be one major project objective, in pursuing it there may be interim project objectives. In lots of instances, project teams are tasked with achieving a series of objectives in pursuit of the final objective. In many cases, teams can only proceed in a stair step fashion to achieve the desired outcome. If they were to proceed in any other manner, they may not be able to develop the skills or insights along the way that will enable them to progress in a productive manner.

Objectives can often be set under three headings:

Performance and Quality

The end result of a project must fit the purpose for which it was intended. At one time, quality was seen as the responsibility of the quality control department. In more recent years the concept of total quality management has come to the fore, with the responsibility for quality shared by all staff from top management downwards.

Budget

The project must be completed without exceeding the authorised expenditure. Financial sources are not always inexhaustible and a project might be abandoned altogether if funds run out before completion. If that was to happen, the money and effort invested in the project would be forfeited and written off. In extreme cases the project contractor could face ruin. There are many projects where there is no direct profit motive, however it is still important to pay proper attention to the cost budgets, and financial management remains essential.

Time to Completion

Actual progress has to match or beat planned progress. All significant stages of the project must take place no later than their specified dates, to result in total completion on or before the planned finish date. The timescale objective is extremely important because late completion of a project is not very likely to please the project purchaser or the sponsor.

Conclusion

Project management has developed over the years, and involves various activities before a project is completed. Objectives should be specific so they are measureable, and although there may be one major project objective, there may be minor objectives throughout the project.

When Do I Turn on Project Management?

By Pierre Monacelli

The problem with project management and IT is that all too often, project management is an afterthought on a project. It is often perceived as "project control" or an administrative function that tracks issues and schedule dates based on best guesses. We are lured to "just get it done" and leap into development without adequate planning. With this approach, project management is seen as providing little or no value, which is understandable because it is inherently reactive when applied this way. Inevitably, projects will exceed prescribed time and budget parameters. To be effective, an organisation needs to invest in project management at the very beginning of the project life cycle. Yes, it does take time to plan and identify requirements, but the choice is to spend the time upfront at a much lower investment and with a smaller team, or spend a lot of time and money doing rework at the end at a much greater cost and with a much larger team.

Consider this scenario: The ABC Company has decided to implement an enterprise-wide technology that will improve and integrate all of its business applications and processes. After lengthy negotiations, the initiative is approved. ABC appoints a programme manager and the technology partners arrive to begin the implementation. The programme manager inherits a few key target dates, set by senior leadership during the previous negotiations. At first, the programme manager is optimistic. But as that programme manager begins to ask questions, it is evident that the devil is definitely in the details. As time goes on, cost and schedule overruns inevitably occur and consequently, performance expectations are dashed. So what went wrong? ABC had a programme management culture, augmented by a seasoned programme manager and a PMO. How could failure be possible given this ideal state of affairs?

And yet, project failure seems to happen all the time. Here are some of the driving behaviours that get us into these situations:

• The implementation of a new product or technology promises to address and resolve a lot of urgent business issues, so it needs to be up and running ASAP.
• Technical experts involved in upfront negotiations focus on the product and coding solution instead of taking a holistic programme management and business approach.
• Integrators make overly optimistic evaluations of how long integrations will take to complete and become accepted throughout the enterprise.
• Upfront planning is avoided or streamlined because it takes too much time.
• A "just get it done" mindset rules the day.

Using this type of "cart before the horse" approach would be the same as a construction crew arriving at the job site with all their equipment and resources, but no blueprints. These approaches undermine what programme management sets out to accomplish. An organisation facing any of these situations will have an uphill battle that will include the following symptoms:

• Re-engineering the upfront planning work that should have occurred.
• Resetting expectations with senior leadership.
• Rebuilding credibility with the user community.
• Managing the endless volume of change requests and rework.
• Explaining early indicators forecasting cost/schedule overruns.

These characteristics (as well as many others) all contribute to the cost/schedule overruns and burgeoning requirements.

So how can you mitigate these problems? The programme management function needs to be introduced and activated before negotiations to begin capturing key upfront information. Before a tool is unwrapped or even selected, your programme manager should know the answers to these questions:

• What business problems are we trying to address with this product/technology?
• What is our expected ROI?
• Who are our stakeholders?
• What are the stakeholder requirements?
• What is our existing business support architecture (processes and enabling technologies)?
• How will our existing business support architecture be impacted (reused, adjusted, augmented, removed)?
• What is our change management approach that will enable us to integrate the new technology into the organisation?

Not only will this information get the organisation off to a good start in terms of programme managing the effort and setting realistic expectations at all levels, it will also enable the organisation to:

• Make an informed make-or-buy decision.
• Help ensure the selection of the right products/technologies.
• Analyse alternatives and maximise re-use.
• Provide a baseline to ensure that the investment (once implemented) is paying off as expected.

After this information is collected and analysed, the programme management function can begin to translate it into the accepted and necessary planning tools (work breakdown structures, control accounts, master schedules, and other PM101 processes) that will support the control and analysis of the programme.

Because we do not live in an ideal world, sometimes organisations may not have the luxury of introducing the programme management function in the upfront activities mentioned here. Some challenges include changes in leadership, strategic direction, mission, priorities, and so on, which may have contributed to an organisation's inheritance of an ill-planned technology investment. If faced with that situation and clear symptoms of a poorly managed programme, the organisation will have to conduct an honest, unbiased assessment to ultimately support a "go/no-go" decision. This is a situation where an independent perspective is paramount. A no-go decision can be very difficult for an organisation, especially if a lot of time and resources have already been committed to the programme. That said, once the decision is made to terminate a programme, the programme management function will be focused on closeout processes and realigning resources. If the organisation decides to continue with the programme, it will have most likely have benefited from investing in a programme "time-out." The organisation can then refocus the programme management function to collect the critical upfront information before proceeding further.

Introducing programme management before an IT implementation can be a time-consuming activity. It takes a lot of hard work involving many stakeholders. But wouldn't your organisation prefer to have this information at hand before the technology is unwrapped and the meter starts running on the hours of effort your employees, vendors, and subcontractors put into costly rework? In either case, there is no free ride. But the upfront ride involving careful planning is ultimately cheaper, smoother and less painful than jolting ride involving brutal back-end rework and cost and schedule overruns.

Project Management Basics

By Michele Webb

If you have ever had responsibility for managing a project, regardless of how little or how big, you will understand the many nuances and special considerations that have to be taken into Post Optionsaccount behind-the-scenes. Project management success stories rarely show the struggles, problems or weaknesses of the project or team to the public. One author, Herbert Lovelace, likened this to the kitchen, which "...tends to be cleaned up before it is shown to guests!"

Understanding how projects should be managed or "by the book" methodology is a good reference guide and tool for everyone. But, in order to succeed the project manager must understand the myriad of people, their needs, and the potential problems and issues that need to be tackled before the project can be called successful. In my own experience, project management is a culmination of all the experiences and knowledge I have gained on past projects and is modified based on circumstance. There are, however, some very broad guidelines that can be implemented to help ensure the project stays on track.

1. Identification

Make sure the problem, or project purpose, is clearly identified before starting. This is best done by putting the purpose into writing and having the entire team review the text. Next, solicit the team's agreement to the purpose in a roundtable meeting. This will also help to identify the customer's concerns and issues that need to be addressed throughout the project and help to stratify the resources and potential conflicts the team may encounter.

2. Preparation

Is all about figuring out what to do and how to do it. Although most of us can handle the mechanics of preparation fairly well on an independent basis, it may be more difficult to ensure that all project team members are in agreement. It is advisable to have everyone sign off on what is to be done and his/her role in the project as part of the preparation. People are far more likely to support something that they understand and have had a role in developing. In our organisation we use a document, called a Scope of Work Agreement, as part of the contracts and negotiation process that details the work to be done on the project. By using this document we can clearly set the project tasks, milestones and timeline before the contracts are finalised. Here's one titbit, if you are trying to implement systems, and you can't explain it easily, don't implement it!

3. Implementation

Just remember, it is always tricky! Try to keep implementation as simple as possible and have a rollback strategy in place. How you react to unexpected issues will make the difference between success and failure. Don't demoralise a team working long hours by letting critical decisions hang or go unanswered. Make sure that everyone on the team is in the communication loop and has a stake in the project. By the same token, don't be afraid to use the rollback strategy if unexpected events sabotage the timeline.

4. Reflection

Is your most valuable tool. We all learn a lot after the project is over about what or how we might have done something differently. It is helpful to keep a written log during the project. The log can also be used as a tool after the project is over to figure out how things could have been improved. A post-project team meeting where all team members can contribute to the feedback is warranted and will produce valuable information from all stakeholders.

Conclusion

Project managers should take the time to learn from formal methodologies and utilise the help from mentors and other experienced project managers. In my humble estimation, though, there is no substitute for the "hands-on" approach to project management and planning. Regardless of the methodology or set of ideals you start out with, nothing will replace the amount of sweat, teamwork, hard work and personal involvement required to successful project management. You can reduce the number of problems and issues you deal with, however, by following these four simple guidelines.

Setting Measurable Project Objectives

By Dr. Keith Mathis

Examine ten projects at random, and you will see some of the worst written objectives. Project objectives are often hard to track, vague, and lacking in depth. In project objectives, people need details to help know where they are in the process, and data helps them make informed decisions. I like to recommend "DISCO" when forming objectives. "DISCO" can be spelled out to point us in the proper direction for creating project objectives and tracking their progress.

D - Detail Specifics

Give as much information as possible and make these objectives very specific. Far too many objectives have been set, which are very grey in nature and lack data to help team members understand all specifics.

I - Include Qualitative and Quantitative Measurements

Objectives must be measured. When you look at an objective, you must ask, "Can we measure this?" If not, it needs to be rewritten so that it can be measured and tracked for successful completion. The only way to do this is to make sure qualitative and quantitative components are set.

Qualitative measurements measure a project based on quality standards, quality indicators, or quality characteristics. Defect ratio, break down ratio, and improvement needs are all to be considered. Each of these can be prioritised and broken down into a specific tracking mechanism to follow and monitor.

Quantitative measurements measure the project based on numerical indicators. Some of the most common quantitative measurements are time, budget, production, work hours, process time, and development progress. Quantitative measurements normally include the need to set a series of benchmarks as a starting point to begin tracking.

S - Seek Consensus With the Team

Making sure the team agrees with the measurement is very important. Sometimes objectives are set at the beginning of the project, and they are very loose. When the team sets a standard of measurement, it will usually be detailed and understandable. It is important because the team needs to be on the same page during planning. They must agree that these standards are the best possible measurements considering the project.

C - Create a Reasonable Approach in Obtaining Those Objectives

The approach for reaching objectives is very important. Unless the approach is understood by the entire team and supported, there will be conflict in the team's processes. Conflict means you will have people going in different directions and using various methods.

O - Operate in a Methodical Timeframe

Setting up a timeline and follow it. This timeline must make sense and be publicised to the entire team. You must constantly focus on maintaining clarity.

An example of a great DISCO objective is, "We will design 15 training courses that meet organisational development guidelines by June 30 with a budget of $483,000. We will include courses on supervision, communication, performance appraisals, and creating an optimistic workplace." DISCO objectives can be very successful in pushing the project forward and bridging the gap for communication. However, good objectives will never write themselves, nor will they track themselves.