As a manager of a team of IT engineers, one of the toughest challenges is getting a handle on not only what everyone is working on, but what are all the seemingly random sources of work coming at your team. Thus whether you find yourself managing a new team or have been managing a team for some time but you are constantly being surprised with new requests out of left field, you may want to consider constructing a logical approach similar to what is being outlined in this series of articles to stop the surprises.
You need to be out in front of the Business and IT
In the first article, we identified the work request attributes of your team and built a list of sources of those requests. In the previous article, we used a great post by Peter Kretzman to build on a more complicated example surround predicting how much project work your team can reasonably accomplish in the future.
In this article, I’ll apply the same approach but to the “Projects requesting engineering support” request attribute which represents work scenarios where you and your team don’t represent the entire technical solution to the business need. Rather, you and your team contribute a portion of the technical solution to another group that owns the final IT business solution. An example would be along the lines of developing a software module that would be used within the confines of a large software application you and your team don’t own. Another example would be you and your team represent a shared IT infrastructure asset/service or application asset/service that involves integrating your asset/service with a larger more holistic IT solution.
Getting your team engaged when a business problem has been identified and another IT group has been requested to map out a solution that they may decide involves your team’s asset/service is challenging from a predictability perspective to say the least. In these situations, rarely does the IT “solutions” group pro-actively engage you and your team when they get the slightest inclination that a particular business problem they are aware of might need integration services from your team. More than likely, since they are under pressure to provide initial feedback and high level estimates, the required due diligence is cut short. The solutions team falls back on past work your team completed for a somewhat similar but never turns out to be that similar guesstimate on your team’s involvement in their half baked solution.
If you are reading this far and identifying with being more aligned with the solutions group than one providing integration services, then you probably want to focus more on the previous article on capacity planning. If you are identifying with being an integration provider, then keep reading.
If you rely solely on the solutions group as your complete end customer, you will always be playing catch up. Arguments such as “If you had engaged my team earlier in the project life cycle/design phase, we could have partnered to map out a more viable solution” fail to work for some of the following reasons:
-
Solutions teams will prefer to by pass the “lack of engagement” discussion rather than participate knowing they indeed didn’t engage your team. What will they do? They will start designing solutions that don’t involve your team’s service. Since they control the requirements, the knowledge and the engagement of peer groups, they can orchestrate a solution that doesn’t involve your team’s service. If you start losing “customers”, at what point will the organization no longer see value in your services and your team in general?
-
If a solutions team does participate in a “lack of engagement” discussion and promises to engage you and your team earlier in the process, what is the likelihood that that same team or more importantly, the leadership of that team will be in tact come the next project? You have achieved some level of “I told you so” agreement, but if the players change on the next project, what does that do for you?
-
From a management perspective, how many times can you claim you had the “I told you so” speech with the solutions group to no avail to your management before your management will begin to wonder why you are stuck being reactive and haven’t put forth a plan to be more proactive?
So, your options with the solutions group seem limited. You need to provide them with engagement criteria, process and procedural info geared to get them to engage your team ASAP for new solutions. You need to have simple contact lists so they know who to call. Also, you need to participate in some level of “lack of engagement” discussion but with a partnering focus, not an I told you so focus as you run into lack of engagement scenarios. You need to provide all this so you can feel confident you are doing everything you can to empower the solutions group to successfully engage your team. In addition, since the solutions group is your choke point for information and knowledge, you need a strategy to get out in front of the solutions group to level the knowledge playing field.
Get out in front, but doesn’t the solutions group have the organizational charge to successfully interface between the business and IT? Don’t they have the project management heavy resource pool and skill set? Aren’t they the first people the business contacts when they think they need an IT solution? Yes, but as mentioned above, if you don’t make in roads into the business camp, you will forever be playing catch up.
How can you get out in front? Make a strong effort to introduce yourself to all the business folks that commonly engage the IT solutions groups. Bring a very simple and brief one page list of services your team provides, in business language not IT, to leave with them. Get them to spill their role in the organization (product manager, application owner, etc.) to you. Try and get them to share their product or service road map. Ask them about their strategy for upgrades, enhancements, changes in the industry that they are reacting too, etc. Your goal is not to replace the solutions group, rather, ask the questions you wish the solutions groups would ask for you but they never seem to ask. Make sure you stress you are not here to say the solutions group is failing, but rather, you are trying to help the organization, as a whole, better align IT services with business needs. I think you will find that setting the correct tone will open a flood gate of information to help you better understand how your services will most likely be needed in the future.
Now that you have some techniques to get out in front of the requests coming to your team, time to put together a way to capture that data in a meaningful way that will better predict when you will be engaged in work. The next article will show a modified spreadsheet for collecting this information in a metrics and data focused format for more effective resource planning.