Tag Archives: Vendor

Make or Break your Project?

0927_testimonial-800x480

The bigger the dream, the more important the team – Robin Sharma

If you go through my blog you’ll see posts that speak about critical success factors for IT business transformation projects. I have talked about the importance of trust, the impact of ambiguity, how to pick the right people, but also vendor performance, dealing with competing priorities and SMART project leadership.

It is not so difficult to BREAK your project; you can do that in a heartbeat. It is much more difficult to MAKE your project. It all comes down to leadership potential of all internal and external stakeholders, because project success is something you create and achieve together as a well-integrated team.

There are a few, silent ‘BREAKERS’ of success that can be detrimental, throw you off track and ultimately force you to pull the plug.

Singing from the same song sheet

Many organizations that initiate an IT business transformation project put their faith completely or way too far in the hands of the vendor. They rely too much on the vendor’s expertise to design, build, test and implement the solution. For these organizations it is a given that the vendor provides industry leading practices to the project. “But that’s why we hired them” is a comment you hear when organizations realize that their expectations are not being met.

Is this an issue caused by the vendor only, or by both the vendor and the organization? It can actually be both. Every organization should develop in-house expertise of the future state solution, otherwise you are not able to define WHAT you want in clearly articulated business requirements. With expertise I mean: knowledge and experience of the business processes, technology and data.

Does it need to be at the same level as the vendor? It must be at least at a point where you can truly understand the options that are being presented by the vendor, and you can identify alternatives that for various reasons do not come forward. Organizations should consider assigning a solution architect (contract or permanent employee) to the project who can bring that level of knowledge and experience. The solution architect functions as a catalyst to other project resources and brings continuity, consistency and integrity of the design to the team. All key resources should be trained in the new technology at the start of the project, preferable by the technology vendor.

The money that the organization spends on building this solid project team capability must be perceived as an investment. It is a risk mitigation activity that has both short term (set project up for success) and long term (effective sustainment) value.

Vendors who embark on IT business transformation projects should encourage the organization to build up their capability right at the start of it and not gradually overtime. It is in their best interest to work with a client organization that sings from the same song sheet, speaks the same language and uses the same communication matrix, from the starts of the design phase onwards. The quality of the solution design drives the value and benefits that the organization has in mind and is expecting to realize.

Silo mentality

It is fairly common that organizations with traditional structures have entities (departments, units, teams, etc.) that operate in silos. We also know that nothing great happens in silos. IT business transformation projects thrive on creativity, collaboration, communication and a multi-disciplinary approach. Organizations can only attract and retain top talent if they move away from this one-dimensional paradigm once and for all. Top talent that is needed to staff the project and future sustainment organization will quickly move on to greener pastures if the organizational culture does not change.

A major risk of silo mentality is that the project will struggle with the “pave the cow path and reinvent the legacy” syndrome. The future state will be not be much different. As a result it does not bring what the organization needs to achieve cost savings, better customer service levels, accurate management information or anything of that kind that makes it better (world-class) than the organization’s peer group. It is not an easy task for the leadership team to successfully deliver the IT business transformation project in this context. What needs to happen?

Executive Leadership can:

  1. Set a new tone for the organization by communicating core values that go with the future state. There are organizations that define core values in a collaborative manner with their people
  2. Clearly articulate the vision, the path to get there, and what contribution is expected from each of the entities
  3. Model the behaviour that is expected
  4. Actively participate in the IT business transformation program with the intention to inspire, motivate and coach people
  5. Set the right business priorities and make timely decisions when needed
  6. Clarify in what functional and technical areas change must happen to achieve major business benefits
  7. Monitor progress and take corrective actions as required
  8. Assign ‘business transformation’ specific performance goals to key leaders
  9. Source top talent from outside the organization that resonates well with the future state
  10. Implement a reward program that encourages people to think, act and speak differently

Project leadership can:

  1. Make sure that project and relevant business objectives, strategy and plans are always aligned and well communicated
  2. Increase focus of change management activities on stakeholder alignment and commitment
  3. Define and enforce solution design principles that drive people, process and technology change
  4. Quickly identify and remove roadblocks on the design path to change, and actively manage integration points or dependencies between entities
  5. Simplify design concepts as much as possible
  6. Implement an escalation path up to the Executive Sponsor to get fast decisions on design issues and risks
  7. Foster a working climate of collaboration, creativity, communication and change
  8. Conduct demonstrations of components of the to be solution to key stakeholders
  9. Implement quick wins where possible and meaningful
  10. Seek for industry leading practices and share that with stakeholders that resist to change

There are a lot of ‘make or break’ project success drivers to think about when you initiate, plan, execute and close an IT business transformation project. Key is to identify and respond to them properly and in a timely fashion. Stay in control of your own destiny by investing in core project team capabilities and by taking the right actions at the Executive and Project level.

Bas de Baat

Program Manager Enterprise Applications, PMP©

A Fixed Price contract, are you sure?

Fixed-price “If you think that a fixed price contract is going to solve all your previously experienced project issues, think twice”

A fixed price contract appears to be the magic bullet to a number of project management issues, but that may only be superficial. At the end of the day, all of the project management routines still need to be flawlessly executed including the financial aspects, regardless what contract vehicle has been selected.

With a fixed priced contract the customer is making an attempt to transfer the financial risk to the vendor. The transfer is at a cost to the customer and wouldn’t exist, if the parties decided to sign a time and materials contract. The additional cost is a risk premium (cost contingency) that the vendor is adding to the base estimate that if done properly already has an effort contingency. It is quite common to see a risk premium in the 10 – 30% range on top of the base estimate and effort contingency together. So long story short, customers are paying a lot extra when they sign a fixed price contract. Is that worth the money; is that worth the delivery risk? Now, there are customers that want to know what the actual project cost to the vendor is and based on the outcome recoup part of that risk premium. Unfortunately that’s not how it woks, because the customer did not bear the delivery risk and also would not chip in extra dollars if the vendor would experience a cost overrun.

Alongside the risk premium (additional cost), the customer bears the risk that the vendor is not delivering the contracted scope with the expected quality (less business benefits). When a vendor is exposed to a fixed price deal, they are managing the project scope very tight. When the project scope is not well defined in the contract and therefore the level of ambiguity (see previous post ‘Ambiguity’) is relatively high, the project is set up for failure. Oftentimes the expectation gap cannot be closed without a project change request, which most customers do not account for in their budget when they have signed a fixed price contract. It is very likely that the gap is significant; therefore the vendor is raising many change requests over time. The relationship stress that manifests between the customer and the vendor, because of the conflict, can be detrimental to the overall trustworthiness of the parties, and when trust goes down, cost goes up, and speed goes down (see Stephen M.R.Covey, “The Speed of Trust”). As a result, the project slides into a downwards spiral triggering all different kind of consequences.

Managing a fixed price contract is asking for a different mindset from the parties than any other contract vehicle. Scope and schedule must be perceived as equally important for both parties. If not, the project is doomed to fail. There are cases where a vendor managed a fixed price contract as it was a time and materials contract. For quite awhile there was an abundance of resources and everything seemed possible (exaggerating here a little bit), but overtime when the project actuals came in and the scope verification check was completed, the vendor realized that the burn rate was way out of line, and that the only way out was raising change requests (extra dollars or scope reduction). At that point, frantic behavior should not be a surprise to anybody. It is possible that the vendor tells the customer that for certain deliverables they have exceeded the number of hours, and the customer has to pay extra. Or that rigorous testing is not required, because best practices and development standards have been followed consistently, and therefore the risk of failure is low. A customer would instinctively think: “But I have a fixed price contract for that deliverable, the requirements are clearly articulated in the contract, blueprint and specifications. We agreed to the delivery approach, what’s the problem?”

These are just a few examples of situations where a customer might end up with, if they make a fixed price deal. They need to be aware of the buyers risk of paying more (risk premium), for potentially less quality (business benefits), and potentially damage to a good relationship with the vendor, whom they may have been successful with before at other projects. What is then the alternative?

There is actually a few. Customers can simply go for a time and materials contract. There is nothing wrong with that if they manage it well. Or customers can decide to go for a hybrid model, where the basis of the contract is time and materials, with fixed price for specific, well-defined scope items. They can also consider performance-based contracts with time and materials as basis. If the intention is to transfer delivery risk to the vendor (which is a great idea and something a customer must consider), embedding performance-based incentives in the contract is a perfect alternative. More and more vendors are willing to demonstrate skin in the game.

The success of any contract vehicle comes down to the accuracy of the scope definition. Customers need to know WHAT they want (see my post ‘Continuity of Vision’) throughout the project lifecycle. They need to clearly articulate it to the vendor, and collaboratively document it meticulously in the contract. When customers are locked into a fixed price contract, discrepancies seem to be much harder to resolve than with any other contract vehicle. Customers must be mindful of the pros and cons of a fixed price contract when they consider it. Customers should not run into it, because they think they have frozen their financial baseline and they therefore only need to focus on scope and schedule. That’s an act of shortsightedness, which at a certain point in time will be proven to be wrong.

Bas de Baat

Program Manager Enterprise Applications, PMP©

AMBIGUITY…

“You can have brilliant ideas, but if you can’t get them across, your ideas won’t get anywhere” – Lee Iacocca

The quote from Lee Iacocca is absolutely true. If you are not able to articulate what you want, you cannot expect that your implementation partner (the Vendor) is able to deliver it to you. Having said that, there is a key component missing. The existence of implementation partners is their expertise and capability to help you define what you want, such that your needs get fulfilled. Oftentimes that is not well understood and/or executed throughout the project life cycle.

tree-swing-project-management-large

Dilbert (by Scott Adams) hits the nail on the head with his strip about a customer that wanted a swing on a tree. It indicates that there is kind of a ‘broken telephone’ between the project stakeholders. None of them actually truly understood what the customer wanted and all reasoned from their own paradigm and communication matrix.

Let’s say for a minute that there is a mutual understanding of the need between the customer and implementation partner. Can it still go wrong? Absolutely. There are many factors that can still make the outcome of the project not to be acceptable to the customer. Think about lack of quality of work, contractual disputes, shortage of resources, resistance to change, competing business priorities, low trust culture, and so on. Having said that, it appears that proper communication is the main success factor.

It is key to sing from the same song sheet, but how do you make that happen? Here are a number of practical measures:

Make communication meaningful: Many verbal and non-verbal communications can be much better coloured with proper wording and visuals such that they become meaningful for the recipient. I have been in many meetings where people leave the room with a completely different understanding about the outcome; at times the complete opposite. Oftentimes it happens, because the meeting is not well prepared. A very effective way to change that is to have the key messages that you want the recipient to take away, well documented on a single page. Use visuals with key words as much as possible. Acknowledge the response and feedback from the audience by paraphrasing it throughout, and summarizing it at the end of the meeting. Document the outcome and send that with the single page to the participants by email. If the subject comes back in subsequent meetings, start off with setting the base line by sharing what has been discussed to date. You want to avoid ‘wheels to spin’.

Synchronize the different communication matrixes: People with different backgrounds who come together in a project to work collaboratively on achieving the project goals need to be set up for success. That is a key responsibility of the customer as well as the implementation partner. Setting the project and team members up for success entails more than conducting a project kick off and reading the project handbook and other on boarding material. Both organizations need to understand that to be effective as a whole, it is crucial that project staff can ‘speak the same language.’ Train your project staff in the software product, methods and tools, project approach, roles and responsibilities, processes and procedures. Maintain a common set of definitions, templates and guidelines. Make this training a repetitive process as we all tend to forget elements over time. Lunch & Learn sessions are oftentimes an effective instrument

Document along the way: ‘Better have it documented.’ If that is part of your style you’ll go far in projects. In my previous blogpost ‘Continuity of Vision’ I wrote about the different kind of documents that you want to use from start to finish. Critical is to be mindful of the fact that WHAT the organizations wants is changing over time as insight grows and/or priorities change. That is a given and both organizations have to manage that change properly and not be surprised of it to happen. Documenting the requirements, design, build, etc properly and consistently along the way can become crucial and a factor of success or failure for the overall project

Build checkpoints into project approach: It is imperative that the customer wants to see what they get well in advance of the formal acceptance phase. Implementation partners can be difficult when you ask them to demonstrate the product while it is going through the design and build phase. It is perceived as a non-productive step or as a delivery risk, especially in fixed price contracts. Understand that Implementation partners do not always have the capability (read: qualified resources) that they signed up for, or customers may change their minds of WHAT they want after a demonstration and they expect that change to be at no cost. This can all be prevented if both organizations agree what those checkpoints are and how change will be addressed as it occurs

Implement an effective escalation path: When organizations engage and embark upon a new project it is the right time to think about how to deal with conflict, because they will happen and when they do, you don’t want them to become lethal. Most of the time conflicts are about WHAT will (not) be delivered at the end of the day from a quality, cost or time perspective. It makes a lot of sense to consciously think about the escalation process from a business and legal perspective before you start the project. Oftentimes it is done from a legal perspective only, without proper involvement from the business, and then when problems occur, it turns out that what is part of the contract is not what the business wants to pursue. Avoid that from happening and define a pragmatic and effective process that has business and legal support. Think about including a mediation and/or arbitration step in the end-to-end process with named internal/external subject matter experts. Build in response times, such that the turn around time on conflicts (issues / disputes) can be managed and the impact on the critical path can be assessed

When quality of communication goes down, ambiguity goes up, cost goes up and the project timeline come under huge pressure. Avoid that and set your team up for success by implementing a robust framework of communication processes, procedures, methods and tools. Train your project staff along the way and lead by example.

Bas de Baat

Program Manager Enterprise Applications, PMP© 

Vendor performance below expectations?

agreement

In business, words are words; explanations are explanations, promises are promises, but only performance is reality – Harold S. Geneen

How often have you experienced that the Vendor (implementation partner), who you carefully selected, does not perform as you expected?  How often have you not been able to turn that around?

Organizations spend a significant amount of time on the commercial aspects of the project. Lengthy and complex selection processes that ultimately lead to contracting the preferred Vendor. Both organizations are at that point in time very excited to further engage, keen on celebrating the partnership, and eager to start the project as soon as possible. Overtime, vendor performance issues start to occur and you are spending more time on corrective actions instead of working with your team on manifesting the project goals.

Vendor performance is a risk area that you must address and manage in the contract negotiation stage. The best strategy to manage it is to transfer a substantial part of the performance risk to the Vendor.

Behaviour drives performance. In order to have the ability to influence behaviour of the Vendor you want to negotiate an incentive score card and include that as a risk sharing agreement in the contract.

The incentive score card contains a number of pre defined and mutually agreed to performance criteria that are directly tied to the payment schedule. Incentives work in both directions. If the Vendor exceeds expectations and reaches a certain score, there would be a financial reward. If the Vendor performance is poor, the organization has the opportunity to penalize the Vendor by for example withholding payments.

It is important that the performance criteria are well defined and unambiguous. Keep it simple. Performance criteria are very similar as the critical success factors of the project. Make a list of approximately 10 criteria and score the Vendor on a monthly basis. You do not want to score the Vendor only at the end of the project or stage or every quarter, because those lapse times are too long. Behaviour can change quickly and you need to have an effective instrument to influence it right away. Doing that on a monthly basis is best. Use a weighted average calculation as some of the criteria have a higher impact than others

There are many ways to define incentive score cards, but to keep it simple consider only 3 performance rating outcomes:

  1. Performance above expectations
  2. Performance met expectations
  3. Performance below expectations

In case the Vendor has met expectations there is no incentive required as all goes according to plan. The organization pays the planned amount to the Vendor. When the Vendor performance is above or below expectations an incentive action is triggered and the Vendor receives a financial reward or penalty.

The incentive does not always need to be a financial reward or penalty. I have used score cards that had non-chargeable consulting hours as incentive. As long as you can quantify the incentive (like $ and hours are) you can be as creative as you want. Be careful though not making it too complex and that you loose sight of its purpose: the ability to influence behaviour and performance.

Here are some scenarios where you have a higher success rate of turning the situation around when you have an incentive score card:

Key resources availability – You are dependent on the Vendor because they have expertise and skills that you do not have at all, or do not have at the maturity level that is required. The Vendor promised you during the selection process that their top notch solution architect is available to the project. Success guaranteed! You were actually introduced to the resource by the Vendor and were very impressed. At the start of the project there are suddenly two solution architects showing up, the resource that was selected and a junior resource. Within a few weeks into the project, the selected solution architect slowly disappears. You asked the Vendor what is happening and for awhile you are being kept in the dark

Action: Identify the key vendor resources, define their skill set and level, and determine when they must be available to execute tasks. Include that in the contract. Consider adding a condition that you have the right to source a qualified resource from a third-party if the Vendor falls short

Performance criteria: measure turn-over of key resources + lead time to replace key resources

Quality of deliverables – You are preparing the deployment of the solution. The go live is just around the corner. There are a number of critical defects outstanding and the deadline is rapidly coming closer. The project team is heads down with hands to key board, working over time and not consistently following procedures, because a lot of work has yet to be completed. The clock is ticking fast, much faster than you have ever seen. Your IT staff has discovered that the development, test and production systems are not in sync and that the overall integrity of the solution is at serious risk. You escalate it and the Vendor tells you: “This is normal for these kind of projects, it is typical and we see it more often at other clients.”

Action: Identify the key deliverables and provide a clear description / specification. Define the complexity level and acceptance criteria. Use external references if needed to indicate the level of quality you are expecting. Design and implement quality assurance and control processes. Train project resources in methods, tools, technology and procedures

Performance criterion: measure on-time completion of deliverables according to specification

Schedule attainment – You are waiting for a detailed project schedule from the Vendor with major milestones, tasks and target dates for key deliverables. The contract clearly states that the Vendor is accountable to create and maintain such a schedule, but does not seem to be in a hurry to provide it. There is a high level GANTT chart that has some merit, but in order to execute the work and monitor progress you really need a detailed project schedule. Meanwhile the Vendor has started the work. You escalate it and the Vendor tells you: “This is how we work, don’t worry, it will get done…”

Action: Collaborate with the Vendor to create and maintain a detailed schedule. Follow a 3 plan level approach: GANTT, project schedule and team work schedules. Clearly document roles and responsibilities for schedule management and status reporting in the contract

Performance criterion: measure on-time completion of milestones and key tasks [you may want to consider using EVM – earned value management techniques, but that can make it more complex]

Vendor performance rating by using incentive systems coupled to payments, is a must have for all major IT business transformation projects. It is the preferred mechanism, because it is following a pre defined and mutually agreed to system between the Client and the Vendor. It is an effective approach to keep your critical business initiative on track and out of trouble.

Feel free to contact me for more information about vendor performance and incentive score card. Just click the email button at the top right corner.

Thank you for reading my post!

Bas de Baat

Program Manager Enterprise Applications, PMP©