There are always trade-offs

If you're following from last week, you probably expected this to be a post about Personal Power. So did we... But sometimes client projects and client problems give us an opportunity to share insights and experiences in almost real-time.

This week is one of those weeks. In that, the title is fitting: There are always trade-offs.

There will always be trade-offs and compromises required. There is often no ‘perfect’ way to move a project forward, and this includes IT projects. The key is to be able to understand the trade-offs and risks and to consciously manage those risks in whatever path you choose to move forward with.

A case in point is a recent customer project. This was a very large, very high-visibility project that had job implications for directors and vice-presidents in the organization. We were brought in to conduct an external 3^rd party design review prior to launching.

When large projects are being led by IT, especially in the private sector, there are a few standard approaches that are taken to address the chicken-and-egg problem: Who creates the new systems? Who operates and supports the current systems while that’s happening? Most organizations are lean enough that they can’t resource both activities from internal staff.

There are trade-offs to either approach:

• Training new people to support your existing systems slows down the project start
• Using your team to build the new system often involves them learning the new before the project can start
• Learning the design skills needed to deploy new technology is difficult compared to learning the support skills required to keep it running after it’s built
• Using an external team that specializes in developing and deploying the technology you want can reduce implementation risk
• Once your external consultants leave, they take a lot of implicit design knowledge with them that your internal team may need to provide ongoing support

There are also less obvious trade-offs that need to be understood by leaders and especially technology leaders because they can influence the success of your project in unexpected (bad) ways.

In this case, the client decided to engage a large consulting partner to design and build their new Enterprise Resource Planning (ERP) solution while the internal team was responsible for maintaining current operations and would take over support of the new system after go-live.

On the more obvious side, when you’re implementing a very complex system, it will take time to transfer the knowledge from the design and build team, to the long-term support team. How long? It depends on how much previous knowledge they have, how much context, and how much they know if the intended solution in advance. When does the knowledge transfer happen? Usually between the time that the system is fully built and tested and before it goes live. If you overlay that project plan with the reality of project delays and already tight timelines, plus a perhaps a dash of reality-inspired cynicism, you’ll soon figure out that the knowledge transfer time is one of the first things to ‘give’ in a schedule.

In this client’s case, they would probably have less than 2 weeks to transfer close to a year’s design knowledge. That’s not unusual, but it’s not incredibly effective. This is 2 weeks time, while all of the final go-live preparations are being done, while the internal team is still supporting the day-to-day operations of the existing system. Once the system goes live, the consulting partner’s team will go off into different directions, already booked on the next client project.

The good news is that was another easy problem to predict relatively speaking, and easy to fix. Whether it’s a post-go-live joint support model that builds on knowledge transfer, or other ways to starting the knowledge transfer earlier and more frequently than normal, there are ways to make this better. The bad news is this was one of the easy problems.

There are two levels of hidden problems. The first level is to anticipate:

• Were the complete and accurate business requirements and technical constraints transmitted and to and received by the consulting partner?
• How many relevant requirements and constraints were missed because they were known at the operational team level? This is especially true when it comes to interactions with other projects in flight.

There needs to be a balance between the strategic and the operational. It is always a balancing act to make choices about new architecture, informed by but not constrained by the current operational context. Good technical leaders and good technical team members don’t focus on the ‘what’ is being done today, except to remember or uncover the ‘why’. That ‘why’ only has value when you view it through the lens of the question, ‘Does this prior requirement or constraint still apply, and does it change what we are doing in the new system?’

The second level of hidden problem is harder to predict:

• While the consulting partner’s team is used to responding to the client’s operational management team, they usually don’t spend a lot of time sharing knowledge with the client support team while the project is being designed and built
• Resistance to sharing knowledge of an incomplete project makes sense to the consulting team:
  • The work is incomplete
  • Things aren’t finalized
  • Any time not spent designing or building is effectively time wasted
  • What if the client’s operational team brings up new issues and new requirements that slows the project down?
• On the flip-side, when the client operations team members ask for details and don’t get them:
  • They feel like there is something being hidden
  • Loss of trust in the consulting partner:
    • Are they hiding something?
    • Are they competent and capable of delivering what was contracted?
  • Unsure whether the final product will actually meet operational needs
  • Unsure of how hard it will be to support
  • Concerned that practical, operational requirements haven’t been considered
  • Feel like they will be stuck making up for any deficiencies in the new system at their own personal expense (of time and effort)

In the Technical to Exceptional course, one of the key points in project success is that if your stakeholders and your users don’t believe that your solution will solve their problem, they won’t use it. If they don’t use it, then your solution, no matter how good on paper, is useless. It provides no additional business value, and in fact, delivers negative value when you factor in the cost.

So, what can you do as a technical leader?

The first thing is awareness. This, combined with your Emotional Intelligence, allows you to better understand what your team needs to hear, know and feel from their interactions with you: to understand how they fit in the overall organizational change, as well as for them to be ready to take on the eventual new workload. There’s also an issue of trust and feeling valued. If they feel like technical realities are being hidden from them, they will lose trust in you. They will feel less valued by you. Neither of these can you afford when you’re leading a major change. With all the other battles you need to fight, there is no point in making your life harder by undermining the support of the direct team.

The second set of strategies involves doing a better job of exposing, and where reasonable, involving your team in the design process. This is not only for the purpose of extracting information from your team, but should be focused on getting your team context, knowledge and the ability to anticipate what their future work will look like. This will make knowledge transfer easier and more effective, and it also helps them be active in getting ready for their new support responsibilities.

In addition to periodic involvement in the design process, key design criteria should be published. Some of these include:

• Expected outcomes and metrics for measurement (what constitutes project success)
• Business Requirements (that the system will fulfill or support)
• Technical Constraints (that the design must adapt to or abide by)
• Any additional context around the Requirements or Constraints including expected interactions with other in-flight projects

To be more effective, if you go back to the pyramid diagram above, things like the proposed Business Requirements and Technical Constraints should be circulated to the internal team for feedback. Not only could you have missed something, or not been aware of changes to other in-flight projects, your team should be made up of the experts you expect to support this system going forward. They probably know a few things that are outside of what you’re focusing on now. Not only can they catch mistakes, incorrect assumptions and provide new knowledge, but they also have a more in-depth knowledge of implicit requirements and constraints because they work with them on a daily basis.

You empower your team by sharing this information, not only do they know what to expect when they have to take over support, but they feel trusted and valued by you. You need that kind of support as you embark on these kinds of change initiatives.

We've covered some of these topics at a high level. Some of them will be covered deeper here in the blog so don't forget to subscribe so you don't miss any of them. If you can't wait for us to blog about them, the answers are in the course.

Join us on Facebook and be part of the conversation!