What’s the worst program management you’ve ever experienced? Chances are, we can all tell a few tales. Who hasn’t witnessed some pretty interesting program management teams or, unfortunately, some horrible events? If you have experienced any of the following scenarios, you might be in the running for experiencing the worst program management ever:
You have an option to either participate in any of the above, continue to drive down the program, or recognize that help is needed and be part of the team that positively turns around the approach. Successful program management is tough. The really great program management teams and methods I’ve been a part of all displayed some common characteristics:
Program management certifications, plans and models are everywhere. A team should be able to get project management expertise into the group and set up a model that is best-in-class. But aside from the setup of the program management model and the delivery plan, consider some of the items above and see if they apply. Ask yourself, the key leads, and maybe some key team members for their view on the topics above. You may find out that you get some great feedback, and that through this feedback, you are building a stronger program management approach!
Why are we so enamored with the term ‘Managed Services?’ Although the term itself conjures up great visions like
- Once and for all resolving my issues with the IT organization,
- Moving to a service-based or utility-based model, or
- Letting someone else deal with the headaches of delivery, while I (and my team) can focus on what the business really needs …..
... we should be aware that our daydreaming needs a dose of reality.
Any of these visions are great and would be a wonderful case study for others to envy, but let’s get real. The reality is that very few organizations take the time to really figure out what they need and what the market can deliver before embarking on the journey to deliver managed services. We are fascinated with the term, thinking it will be as simple as turning on/off a light switch. We fail to remember everything that went into making that light switch work to begin with and what makes it continue to work well. Instead of getting caught up in the lore of ‘managed services,' take the time to figure out what you need in order to bring managed services into your environment. There are some great successes and some equally great failures. Try a couple of these techniques and see what happens:
The techniques and approaches for managed services are currently evolving. There will be more to come as this area evolves. We will continue to be enchanted with the topic of ‘managed services' - hopefully moving away from that first blush of fascination to the reality of the work required for successful market delivery.
Why do most IT and Business Transformation projects fail? IT and Business Transformation projects often fail for the same key reasons, namely;
Without having the ability to recognize and resolve these issues, you are probably doomed for failure. Instead of walking into this trap, here are a few techniques you can try to help you and your team be more successful.
Failure Premise – Not being realistic in terms of what can be accomplished
What are you really trying to do? Has anyone done this before? To be more realistic, take a look at whether or not your overall plan makes sense: Are you taking some key initial steps, like piloting and prototyping your solutions before going for the ‘big bang?' Look at each item of delivery and define what the criteria are for success. If you don’t have a plan, or can’t figure out a plan, how will you know what can be really be accomplished? Each item in the plan should have a simple measure that will tell a powerful success story.
Failure Premise – Putting the wrong leadership and team in place
How often have we sat in meetings and said to ourselves, this leader is not getting it or this team is doomed? This happens more often than any of us want to admit. IT and Transformation projects will often get trapped in the depths of detailing the leadership team, the working team and the time commitment of each person. This is often a cover-up, knowing the right person for the project is probably not available or can only give you 25% of their time, so the team has to juggle the rest. If you find yourself caught in this situation and you are not getting the right people to either lead or become part of the team, STOP the initiative! Don’t move forward until you can get the right people in place. And make sure you are applying this rule to the WHOLE team, meaning your leadership, the vendor leadership, the IT leadership, the business leadership and any other vested group that plays a role.
Failure Premise – Not knowing how to avoid the ‘big bang’ of delivery
If you are sitting in the planning or team meeting and someone puts on the table that they are going to go live and do it all at once or in a ‘big bang’ approach, alarms should be going off in your head. Having been burnt on this topic several times, get real and start raising questions that will get your team on a successful track.
Transformation projects are not about big bang. They are about the ability of the projects to drive change that is transforming on many levels. In some cases, you and your team may not even have a clue of what the actual results will be one to two years after you 'go live.' Why not get in front of this and create your own destiny, roll things out in smaller batches of delivery, use a trusted partner to help you test and prove what you are doing before rolling it out to the larger organization? Plan for failure in a pro-active way that will allow the team to learn from the events and move forward, rather than experiencing a ‘big bang’ failure and not being able to recover and move forward. Manage the risk profile so that you can get the best from the real capabilities of your team.