Delivering Transformation with Precision

You’ve just walked out of an operations review, only to hear that another project has not delivered as expected. The team lead had been called on the carpet, having to explain what has gone wrong with deployment and what actions are going to be taken. The team lead has just completed a lackluster review of the project’s current status and most of the meeting was a critique of actions taken and the directive to fix the current problems and then report back to leadership. You have now witnessed so many of these meetings, that aside from the specific crisis at hand, you have the gut feeling that ‘there has to be a better way!'

It is likely that your  team and organization has become overwhelmed and  too focused on remediating current issues. The same issues continue, happen repeatedly and the result is that there is little or no change to the conditions that created the problems in the first place.

There is a better way and a solution. I’m calling it “Precision Transformation.' My definition of Precision Transformation includes the specific activities, metrics, measures and change management required to deliver results with precision.

My premise is that although IT organizations are well known for gearing up a project plan and project team to deliver a solution, there is limited focus on delivering with precision. Given the complexity of delivering results, the focus needs to change.

Driving precision transformation will change IT delivery, whether it is in the execution of the software delivery life cycle or  in IT operations. To make this happen consider the following:

Defining Need: Are your customers able to accurately describe what is needed? This goes beyond the classic use of business analysts to refine customer requirements. If the customer cannot define the need with some level of detail, then why are we doing the project to begin with?  Three simple questions to ask when defining the need include:

1) Is the need defined in detail? 

2) What is the expected impact to the end customer? 

3) What will this new functionality do to  current state operations?

Quick Hint: If you cannot define the need with some detail, then why are you doing the project ?

Defining Delivery:  Ask your customer to close their eyes and define the perfect delivery.. aka ‘nirvana.' Three simple questions to ask include:

1) What does best in class delivery of the solution look like? 

2) What does delivery look like for operations and IT?

3) What would be their worst nightmare …things that could go wrong?

Quick  Hint: If the customer cannot answer all of these questions, then go back to the drawing board!

Defining Operations: Pull out your current documented operational and IT models, all the metrics, all the reporting and examples of  the operational reports that are created today.  Or if you don’t want to collect this data, draw it on the white board.  Ask you team these three simple questions:

1) What are we going to eliminate / improve / change with the rollout of the new initiative? 

2) What is the impact to our architecture and infrastructure when rollout happens?

3) What steps were taken throughout each phase of the SDLC to make sure operations are going to be robust?

Quick Hint:  Ask these questions at the start of project and ask them at the end!

Preparing for Change

We all know the saying "change is never easy," and have probably heard this when embarking on a new initiative or program. You may be calling the team to action or working to roll out a new program that will face significant challenges. In order to prepare for the change and take control of the situation, think about these key areas and what you can do:

 

Governance – The governance model needs to cover both IT and the business. Instead of defining a governance model and rolling it out to your business partners, why not engage your partners in a quick worksession or interview exercise to define what each party wants to see as a part of governance. For example, a common, combined taxonomy for measurement across both IT and the business can go a long way in running an effective governance model that drives value from the IT organization to the business.

 

Value – Understanding the contribution of each partner in the delivery model is critical. Bringing together the combined team to define the value proposition and the desired outcomes will clarify objectives and help when faced with new demands and the need to re-prioritize projects, activities and other initiatives. A clear definition of value that can be periodically revisited when demand changes can be an effective tool to minimize the noise and keep the team on track.

 

Measurement – In order to prepare for the change, one of the most challenging aspects is how to measure success? What does successful completion of the initiative look like? Take a first step and forecast what you think the measurements should be. Then take the next step to determine if you can actually deliver the measurement, by collecting the data and then presenting it in a simple and concise manner. You may have a formula and a specification for a great measurement but gathering the data, analyzing the data, or explaining the measure may be more difficult or costly than the ultimate value of the measure. Strive for simplicity, look for measures that are not only practical, and look for fewer measures, not more.

 

Accountability – Understanding what each group brings to the table is critical and a great team exercise. A quick roundtable to get the opinion as to the role of each team member will probably demonstrate that accountability is not clear. Take the time before you begin the initiative to clearly identify accountability. Walking through a few examples and sample change scenarios up front will go a long way and help to eliminate confusion.

Vendor Contracts: 14 things to watch out for

One of the tricks to a successful contract and vendor relationship is the actual strength and flexibility of the contract between both parties. Aside from the typical ways we setup contracts and use industry standards, we also need to consider the key areas that we should be watching out for… or better yet… what are the "gotcha’s" that you need to be concerned about?

 

If I was explaining this to someone in a leadership role, I’d want to make sure the following list was incorporated into our discussion. Narrowing this down to 14 areas was tough, but here goes:

  1. Vendor Capacity – Do you know what the vendor has in place today, what is planned to support future deployments?
  2. Increase in Volume – Can vendor delivery scale to meet increased demand or services? For example, if you do increase the volume of work, have you pre-defined your expectations for pricing and delivery?
  3. Transition – Has the transition been defined with explicit deliverables for pre-transition, transition and post-transition.
  4. Current Staff – What will you do with the staff currently performing services? Will they become part of or integrate with vendor delivery? Who is driving continuity and knowledge transfer?
  5. Contract Changes – How will both parties deal with changes to the contract?
  6. Vendor or Client Default – If something happens, has the model for remediation been defined prior to the contract execution?
  7. 3rd Party Default – Has the model for remediation been defined if a supplier in the chain of delivery defaults or is not able to provide services?
  8. Proprietary or Confidential Content – How will the vendor maintain the confidentiality of content across the delivery model?
  9. Governance – Is there a complete governance framework in place for managing the execution of the contract for all parties - you, the vendor and any 3rd party suppliers?
  10. Contractual Structure – Has the contract been structured with the right tools to sustain and address prospective areas of risk?
  11. Data Privacy and Security – Has the combined team addressed privacy and security requirements in a proactive and continual manner that does not pose risks?
  12. Risk – Have you looked at each operational aspect of the contract and identified what actions would be necessary if the risk becomes a reality?
  13. Communication – Does the contract address both internal and external requirements, with a pre-defined approach for effective communication and change management?
  14. Lack of Investment or Commitment – Do you have the appropriate commitment for all parties to address oversight, contract commitment and the proper access to required tools? For example, what does your contract specify regarding 3rd party software access rights?

The items above are just a handful of key considerations. There are many more items to consider and take into account when delivering a strong and flexible contract between both parties.

IT Consulting – Acting as a Mobile Application

The traditional “Big 4” or "Big X" IT consultant model is in dire need of radical change. Recent
experiences indicate that although the technology industry continues to morph and deliver to client
demands, the client is really looking for the IT consulting industry to do the same, and act as a “mobile
application."

 

Some recent examples bring this into focus:

 

1. A consulting need is often immediate. The client only needs the consultant for a specific period
of time (it may only be one hour or one day, not months) to meet a very specific need. Although
the delivery of some programs may require large amounts of committed consulting time and
resources, the bulk of client requests are not these “big ticket” items. Clients are looking for
consultants that can react quickly, and answer the need with straightforward content and value
added material. If you had one day to accept and respond to a client request, what would you
be able to do?
2. The need is specific. The C-level folks are often looking for a specific piece of data or value
added input in the short term. The trick to meet the specific request is to focus sharply on the
immediate need. Answer the need, but also make the effort to ensure the client understands the
full ramification of what they are asking for by putting the answer in context.
3. It has to be cheap and useful. Just like the mobile application that you love and use all the time,
part of the reason you are using it is that the cost is cheap and the content is consistently useful.
With lots of competition out there for IT consulting and rates becoming more cost competitive,
the consulting help has to be useful. Forget about initially supplying the client with lots of
PowerPoint decks and “fluff.” Give them what they need. And then later send them a link to
more items (again, just like the mobile application).

 

It may tough to do everything on this short list, but start thinking about your delivery from the view
of your client. Their time and focus is limited and they are often in a position where they must move
forward with a business decision quickly. The legacy models of IT consulting are going to be become
more like the mobile applications we all love to use and can’t wait for the next one!