Midwest IT Survival

Can I get the impossible delivered next week?

How many times have you participated in this typical IT conversation?

Business: “How long is it going to take to enable that new FlimFlam engage-the-client-better module with those extra customizations we talked about?”

IT: “Last time we looked at that we said it would take a little over three months including changing the custom code in order to be able to use that new module.”

Business: “Well, we need it turned on by the end of next month when the marketing campaign starts.”

IT: “Um, err, change all the custom code, install the new module and enable it with those additional features in two not three months?”

Business: “Yes.”

The theme of this classic IT delivery challenge is the same:

In order to meet a communicated business need within a business defined time-frame, a perceived number of technical tasks need to be accomplished that don’t initially appear feasible in that given time-frame.

The initial reaction by most technically minded people is this is completely impossible.  And yes, Agile or other project delivery methodologies have built in capabilities to handle fixed dates and variable scopes.  But if you are faced with this common theme of questioning, I am going out on a limb and guessing you are not working in a truly Agile shop or else this question isn’t likely to be asked in this manner in the first place.

So, you rush out and grab your FlimFlam experts to communicate the need and the desired end date.  You tell them this is the most important thing to work on and then you go back to your desk to get ready for the next crisis of systems delivery.

Nope.

Consider taking the time to put together a work delivery estimate as your first priority.  Why do this seemingly futile exercise when the business has already stated what they need and when they need it by?

You need to have some estimate data in hand to have a conversation with the business on what is truly feasible within a pre-communicated time-frame.

This conversation serves a few purposes that are critical to you and your team’s ability to deliver a quality solution:

• Establishes what in-flight work will be put on hold/delayed until this higher priority request is completed.
• Durations of time on sub-tasks enable the business to prioritize what features they truly need versus those that are just “nice to have”.
• Establishes a baseline so when other high priority requests come in or new feature requests are added, you can dust off the previous estimate, revise with the new needs, and re-engage in the conversation.

I can’t count the number of times I have chatted with a business sponsor that swore up and down they just had to have every item in their request delivered by an irrational date.  Yet when presented with some work estimate that indicated everything wasn’t realistically possible within the time-frame [based on the cumulative hours/weeks associated with their request broken down into granular tasks], that same business sponsor started cutting “low priority” features left and right to meet their date.

Business: “You mean it is going to take a week just to get that data on the screen within the application?  We can just use that old report that shows the same data on paper.  Scratch that feature.”

Technical/Engineering Challenge

The typical technical/engineer mindset applied to the theme of delivering unfamiliar technology within an aggressive (arbitrary?) time frame is to think it impossible given the number of unknowns.  Get ready for panic and shortness of breath from your less seasoned technical staff.  Giving them coaching and a framework to break down the seemingly huge and complicated requests into a logical sequence of executable tasks is the other side of the estimation challenge.

To help enable the technical resources to break down “the work” into meaningful, estimate able and negotiable chunks, I’ve attached a simple work estimation spreadsheet:

Sample IT Work Estimation Template 10-05-10 [xls]

Sample IT Work Estimation Template 10-05-10 [xlsx]

Below is a brief explanation of how the template works:

There are three tabs:

1.      Template = where one fills in the data to create an IT work estimate.

2.      Calculations = where certain values are used in calculations on the Template sheet.  Changing numbers here causes the whole estimate to change.

3.      Assumptions = certain assumptions, copyright and reference back to this article for explaining how the template works.

Template

The top portion of the template (red arrow below) is designed to capture the basics about the estimate to tell it apart from other estimates: Name, project, dates, etc.  Think of all the fields that would help you and your organization know what you are estimating.

The main section of the template is where the work break down and granular task estimating occurs.  Gray fields throughout are auto-calculated but can be typed over if needed.  The first task heading “1. Architecture Tasks” shown below is a section to capture the non-negotiable tasks that need to be executed in order for any business functionality to be delivered.  This could be getting servers installed or setting up a new project in MS Visual Studio 2039 or creating a new code branch for the required new features which involves an act of Congress in your organization.

The “description” column is for the estimator to describe, in low tech language, what granular task is needed.  Since one may need to sit down and discuss this with a non-technical business person, some effort to use language that is more descriptive and less heads down techie would be beneficial.

The “Low” and “High” are for the estimator to enter the approximate minimum and maximum hours needed to complete the task.  The “Average” column in gray is calculated as simply the average to be used for the roll-up calculations at the end of the template.  If there are a number of unknowns or the tasks could be quick but depending on X, Y or Z, might run long, use a wide range for “low” and “high”.  This also presents the business conversational element of “Well, if this step goes well, it could be as short as 3 hours.  But, if turns out we do need to engage the storage team and get more storage allocated, then this could take as long as 20 hours.”  This is useful in setting the business’s expectations around variability in the estimate so they don’t get too fixed on a single, implicit number when things don’t follow the “happy path”.

The “Actual” column is useful for the engineer to record the actual time it took them to complete the tasks or the number of hours consumed up to the date the template is revised for some status reporting reason.  This also paves the way for estimators to get better at more evidence based estimating/scheduling.

The “Complete” column is for the task executor to record if they indeed completed the task or if it  still needs work to finish.  Entering a “Y” means the task is complete.  Blank or anything else means the task still needs work to complete.

The “Estimate Remaining” is gray and thus calculated as the remaining hours of the “Estimate Average” minus the “Actual” if the “Complete” column doesn’t have a “Y”.  If the “Actual” turned out to be more than the “Estimate Average” then the column is left blank.

The “Notes” column (not shown here) is for any task notes that help the estimator or anyone reading the estimate to know some additional details about task that is driving the estimated hours.

The next section called “2. Development of Functional Unit 1” represents a block of work that roles up to some business identifiable chunk of work.  Feel free to change the section name to reflect something all project stakeholders would understand.  These sections are designed to be the negotiable features that can serve as that business conversation to determine what are the exact features needed and the corresponding work durations.  Feel free to cut/paste as many new sections as is representative of the work break down requested.

In the above example from the template, Sample Task 2.1 represents a task that was estimated to be 7.5 hours but actually took 4.5 and is compete.

Sample Task 2.2 represents a task with 18.00 hours completed so far, thus calculated is the remaining 5 hours from the 23 hour estimate.

The “Sub Total” represents the min/max of the total work effort (142.25 and 181.25 in this example, which is a full ~40 hour delta) for an average of 161.75 hours of which 65 have been completed and 101 hours remain against the average.  Thus, the business expectations can be set relative to the ~40 hour swing to help the planning for best and worst case delivery.

Below the “Sub Total” section are tasks that are relative to the overall IT work:

In this section, any standard deliverables or work associated with the doing the actual development work can be captured.  In this example section, I added “unit testing” which I calculated as a percentage of the sub total hours of development work above.  The percentage is pulled from the “Calculations” tab.  In this case, I am calculating that unit testing takes 80% of the hours estimated towards development.  You can add/remove entries or adjust calculations on the “Calculations” tab to capture the hours needed to deliver a quality solution that so many developers forget to include in their hard core development work estimating.

The two documentation entries represent either a fixed amount of time, in this case 10 hours, or hours that are a percentage of the total development work, in this case, 20% of the total hours.  Feel free to add and subtract items that come up regularly to make the overall estimate more complete.  Need production turn over documentation?  Add an entry here.  Need some change control document to push a solution into the next environment?  Add an entry here.  Over time, this section will settle into capturing the work that is regularly needed in every project but is easy to forget to estimate for each time.

Lastly, the final section includes the total hours for all the work which is especially useful in answering that initial question: “How long is it going to take to enable that new FlimFlam engage-the-client-better module?”  One additional element that helps beyond the “how many hours” is the “Total Work Days” calculation which is based on a more realistic number of productive hours per day plus any reduction in time to cover other assignments that aren’t specific to project work such as researching a new technology or working on a special assignment of some kind.  The calculations are in the “Calculations” tab.  In this example, the productive work day is 6 hours (not 8 as some might consider) and 80% of those 6 hours should go to projects such as this one.  Hence the “Total Work Days” is greater than simply 348.50 divided by 40.  Again, feel free to adjust these calculations to aide in matching what your resources truly can dedicate to a particular project.  Want to show the “cost” of assigning two concurrent projects to a single resource?  Drop the hours to 3 and add another 20% to cover the cost of “context switching” and see how your estimates come to reflect reality a bit more as an example.

Additional Value

Once established as the “baseline” estimate, as new requests/changes come in, add them to the previous estimation sheet, change the date and quickly be able to predict when the overall solution will now be delivered.  Get ready for another “what is pushing out the date?” discussion armed with your estimating data.

Once established on multiple projects in the “portfolio”, now you can hold these up against competing resources to show “if project X goes first, when would I get project Y next?”  This is extremely handy if your resources effectively cost “zero dollars” in a non-charge back type corporate IT model.

Please give this template a try and let me know feedback on how effective it is with technical resources as well as a conversation tool with project sponsors.

For additional practical estimation articles, consider these I’ve written in the past:

• Is the Gantt Chart Useless in Agile Projects?
• More Pitfalls of Work Estimation
• The Art of IT Work Estimation

Also, for an excellent article on using a similar technique on prioritizing multiple projects, consider this great post by Peter Kretzman, “The Practical CIO: Difficulties in project prioritization & selection, part 2“.

For additional caution in getting too carried away with the accuracy of your estimate, consider Todd Williams’s article “Good Estimates Only Have a 50% Chance of Being Made”.

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.

Project Portfolio Management Lite

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.

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 covered an example of using the work capacity metrics to support a frequent management question around the lack of project work progress for a team with additional production issue support responsibilities.

So, we have seen how the use of work capacity metrics data can be used to capture the impact of difficult to predict production issue support competing priorities.  Let’s build on that with a more complicated example surround predicting how much project work your team can reasonably accomplish in the future.

A common question to an engineering manager that will be repeated over and over is: “We need to accomplish X and Y and Z … oh, and we need to complete the first Q milestones of project L … can we do all this by the end of the week/quarter/year?”

A completely valid question, but one that is incredibly challenging to answer:  Clearly, the requestor is asking for some degree of confidence that all of this work can be accomplish or if it can’t, what can be reasonably expected and to what level of completion.  Based on the answer, the requestor may consider re-prioritizing the work, or reducing “nice to have” features/capabilities or determining a completely different, potentially non-IT solution to a given problem.  Given an answer of “I don’t know” or “I can’t tell you” or worse “yah, sure we can” without any shred of data to support that claim, the organization as a whole is already heading for a disaster of some magnitude.

Now, any IT project manager reading this is going: “hey, I do this for a living, let me take over …” I agree.  What we are embarking on here is a slimmed down form of project portfolio management.  From the engineering manager’s point of view, you have a fixed set of resources.  You have work requests you have little to no influence over that you have to support.  You also have work for which you have more influence but you probably have more work than you can reasonable staff with a simple: “Hey, Bob, go dedicate 100% of your time to Project X and come back when Project X is done for your next assignment”.

Feel free to type in “project portfolio management” into Google and be prepared for an onslaught of material to sift through.  Try the same in Amazon or even the shelves of your local bookstore and you will find mountains of material on theories and approaches to this topic.  But of all the material available, for someone that is looking for a quick and simple way to put together a mechanism to use some loose metric data to predict the future, I highly recommend Peter Kretzman’s post on his blog “The Practical CIO: Difficulties in project prioritization & selection, part 2” [].

In essence, you need a tool to help you put some metric data you have together with some work estimation data you extract via the requestor to produce some map of the likelihood, given your fixed resources and non-influence-able work requests that you can complete some portion of the work requests by some arbitrary date in the future.  Or, stated another way, what you are trying to predict with data you can explain, the intersection between the number of resources you have, minus the percentage of time they spend on non-project work against the number of projects and associate work duration estimates.  If you take on two many projects at once, your resources will be spread so thin they will predicatively miss deadlines on all of the projects.  If you take on only a few projects but the work is lengthy and sequential in nature (waterfall application development comes to mind) for individual resources, then you will have idle resources but hours and hours of work ahead of the few engaged resources.  As I mentioned above, Peter has put together a straight forward explanation with a simple MS Excel template you can start using immediately which I highly recommend you explore.

After exploring, you should be in better shape to handle the negotiations that ensure when project work requests exceed your team’s delivery capacity.

In the next article, I’ll apply the same approach to the “Projects requesting engineering support” request attribute.

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.

Do you want to go in front of your boss with just your gut?

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 dove into team capacity metrics to put some data to the hunches around who is working on what for how long.

So, you have your work request attributes and you have the beginnings of a single model of how your team does work with some numbers to show your team’s real work capacity.  Now let us tackle some way to use those numbers to put some data against those attributes.

Remember from our first article the sample attributes we compiled and determined the level of control or influence you have over the request flow?

Influence:

• Vendor product end-of-life = vendor products that you have purchased and currently use that will ultimately reach a vendor dictated end of life date by which you can no longer get support from the vendor thus you should/have to upgrade
• Vendor product upgrades = instead of the vendor forcing an upgrade due to a product’s end of life, you may need to upgrade a product prior in order to take advantage of new features and functions, etc. you or someone desires
• Service Strategy = the IT service that you provide to the organization needs to keep up with new demands on the features you provide externally as well as the time/energy spent keeping the service functioning internally.  This is greater than just “upgrade to the latest version” but could entail workflow changes, process or procedural changes, etc. that mean some level of work impact to your team.

No Influence:

• Production issue support = ad hoc requests from outside your team for subject matter expertise to assist with resolving system production issues or ad hoc “consulting” such as assisting peers with solving a problem based on your team’s expertise
• Projects requesting engineering support = business sponsored projects that require some resource assistance from your team

Now is where your capacity metrics come in handy to try and be more predictive around the work you have no real influence over.

Production issue support

Looking back at the numbers you have collected about your production issue support, what can you say?  Well, for a given time period, say an average 5 day work week, you should be able to make a data based claim as to the percentage of time your team as a whole spends on this activity.  Is it 5% of your team’s total capacity or more like 30%?  Taking the time captured per the previous article’s approach, you should be able to determine a percentage of total time claim that is supported by data and not just your gut.  The data based rather than gut based doesn’t detract from the value you place on your gut instincts, but rather, should be re-enforcing your notions concerning the impact of this service that your team has to provide.  Consider this management exchange:

Gut Only:

Big Boss: “Why can’t we make consistent traction on the FlimFlam Upgrade project?  Each monthly status meeting seems to show some progress, but never the progress predicted the previous week?”

You: “Well, we can make some traction but our resources get distracted with production support issues that take precedence.”

Gut Reinforced by Capacity Data:

Big Boss: <same question>

You: “Well, we can make some traction but our resources get distracted with production support issues that take precedence.  In fact, over the last N months, in tracking the hours the team devotes to production support issues, the data says the team, on average, is spending 30% of their time focused on production support issues.  Thus, those hours are not available to the FlimFlam Upgrade project.”

I think everyone would agree that the second response has more credibility because it backs up the “gut” with data that puts real context around the impact of the higher priority work requests.  Further, it suggests that only 70% of the work projected for the FlimFlam Upgrade project can actually be accomplished thus closes the gap in the Big Boss’s question around work not getting done.  Said another way, a conservative maximum of 70% of the next month’s predicted work should be expected to be accomplished.  So, now you can add a proactive element to your response to the big boss’s question.  Consider this addition to the above response:

“I would like to propose, unless you disagree, that I contact the project manager on the FlimFlam Upgrade project and ask him/her to forecast the month forward work projection and then a second forecast showing only 70% of that projected work getting accomplished.  That way, we all collectively will have the best projection of how much work will most likely get accomplished given the competing priorities of production support work.”

The data backed gut with proactive forecasting response presents a much more comprehensive answer to the Big Boss’s question than just gut alone.  Plus, going forward, at the FlimFlam Upgrade project meetings, the progress (either greater than or less than 70% in this example) can be tied to the impact of higher priority work requests rather than some nebulous unknown reason that could be left to the interpretation of stakeholders.  More work than the 70% got accomplished?  It must be less production support work.  Less work than 70% got accomplished?  It is more likely to be a spike in production support and not ineffective resources or your weak management of those resources.

In the next article, I’ll apply the same approach to the “Projects requesting engineering support” request attribute.

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.

Real work capacity in a work day = 5 or 6 hours? Really?

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 combined these two lists into a single model of how your team does work.  This article we will dive into team capacity metrics.

So, you have your work request attributes, you have the beginnings of a single model of how your team does work, now let us start to put some numbers together to show your team’s real work capacity.

Easy, each engineering resource works 40 hours a week; done.

Or … how about getting a bit more sophisticated:

40 hours – 3 weeks of vacation – 8 holidays = 36.5 hours per week or 7.3 hours per day.

Great … we are done … this was easy!

Well … there are whole companies focused on delivering this number to an organization based on their proprietary way they take into account inefficient processes, status reporting, change traffic and group/team/feedback meetings.  This article contends that 6.5 hours a day is what resource capacity planning tools generally use as a guess for effective work hours in a day.  In the very same article they further challenge 6.5 as being too optimistic and suggest 4 to 4.5 hours a day is more probable.  Something tells me if you were to approach your management with a claim that your team is really only able to do 4 to 4.5 hours of work in a given business day you would be on a fast road to picking up your last paycheck.

But at the same time, to say your team is productive on engineering activities 8 hours a day or even 7.3 hours a day would be equally unrealistic.  So how does one arrive at a plausible number?  I will venture to say it involves one part science to one part “guesstimation”.

Science:

Do you have any sort of time reporting/tracking system?  If you do, you are in great shape as far as useful data is concerned.  Before you go digging for metric gold, you should consider pinging each team member to see how they actually approach time entry.  Do they just put eight hours every day without any delineation for different projects or meetings or even lunch?  Make sure you assemble how your team is entering time before making any assumptions on the data you are mining.  You may find it helpful, after chatting with each team member, to create a time entry guide so you can help get everyone pointed in the similar direction.  After handing out the guide, start re-checking the time entry data to see if everyone is consistent or if you need to revise the time entry guide to course correct.

Guesstimation:

So you aren’t lucky enough to have a time tracking system of some kind already in place.  You could try and whip up something in say MS Excel and collect files from everyone each week.  Or, you could go find an open source product such as WR Time Tracker* or My Time Card*.  Or, instead of having to figure out a way to convince your team you really are trying to do a more scientific capacity planning exercise with real data versus being the “The Man” and wanting to track their every trip to the restroom and the coffee station, you could make an educated guess.  Try this:

In given month there are 20 working days on average thus at 8 hours a day, someone could be working 160 hours in a given month.

Catalog every team member’s allotted vacation time, holidays and sick days or whatever allows an employee not to be at work.  Average across your team members (since we are guessing) and compute to total hours.  Subtract that number from 160.

Do you have a team meeting every month?  Subtract one hour per month.

Do you have a department or large group meeting monthly or bi-monthly?  Subtract that as well.

Your probably have other meetings for human resources functions or life safety or company training or design reviews or architecture reviews or committee meetings: determine those monthly and subtract as well.

Don’t forget any external training, conferences, seminars, etc., average and subtract those as well.

You may be surprised to find when you sit down and figure out all of the “corporate distractions” from doing actually hands on engineering work, you end up with somewhere between 5 and 6 hours of actual concentrated engineering work time.

Now, are you wondering why your project estimates always seem to fall short?  Have you sat down and gone through this exercise?  Even if you haven’t gone through this “guesstimation” exercise, pick a recent project that ran longer than estimated and try using a 5 or 6 hour work day instead of 7 or 8+ and see if you come closer to the actual target.

Anyone else have any tips in this area or a handy MS Excel template they can share that makes this easier?

The next article will dive into a very simple project/request capacity exercise.

*I have no direct experience with these products.  Review their terms and conditions and product feature set prior to installing and/or purchasing.

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.

In the previous article, we have identified the work request attributes of your team and built a list of sources of those requests.  In this next article, we will start to combine these two lists into a single model of how your team does work.

Step 3: Separate request attributes you can influence from those that you cannot

Just a note right off the bat … I chose the word “influence” rather than control or direct.  I rarely find one has complete and total control over every aspect of a particular work request attribute.  Thus, the work model needs to be flexible to handle changes even to work requests you yourself are sponsoring.

From our example engineering team in the previous article:

Influence:

• Vendor product upgrade = If you are taking the proactive step of upgrading a vendor product, then you have an increased level of influence over the scheduling details.  The most notable exception is if you are opting to make a vendor product upgrade a dependency on an external project’s requirements as I’ve outlined in the following article on this technique.
• Vendor product end-of-life = although you don’t have influence over when a vendor decides to establish an end-of-life date, you usually have plenty of advanced notice.  Knowing your product has a six, nine, twelve month life, you can proactively plan how to upgrade to the appropriate version.
• Service Strategy = probably the request attribute you have the most influence over.  Also, when the work is piling up, this is probably the attribute that gets the least attention.

No Influence:

• Production issue support = the classic “drop everything, all hands on deck” scenario that pops up when you least expect this type of work request.
• Projects requesting engineering support = If you want to continue to enjoy your paycheck, when an external project requests resource assistance, you probably aren’t typically responding with “we are too busy, come back next year”.  Rather, you need to provide each and every project that is integrating with your team’s services with some form of assistance.  Since project scopes rare stay fixed, the likelihood of having little to no involvement in a particular project will turn 180 degrees and need your services puts this attribute in the no influence category.

Step 4: Identify sources of predictive data per request attribute

Time to start identifying some metrics

Now that you have categorized you request attributes into those that pop up at random compared to those that you have some influence over, it is time to identify sources of data to use as metrics to drive the model.  Why are metrics so important?  Because as an IT Manager you need a library of complex colored charts and graphs to swamp senior management with to justify your role in the organization; more seriously, in order to make credible claims.  Proceed to identify per request attribute sources of metric data:

Production issue support

Most if not all IT shops have some product trouble ticket tracking system of some kind.  Get yourself access to whatever reporting capabilities exist and try and get as much data extracted as your can.  The data should specifically note in some way your team members’ involvement.  Can you extract patterns?  Do you see a spike of involvement at the beginning or end of the month?  Is there a customer billing cycle that has your team helping the billing department five times every second week of the month?  Can you pull any start/end times your team is involved such as the average time spent per ticket is 1.5 hours?  This is the kind of trend data you are looking for to start turning the “we keep getting surprised with all these production tickets” into “we can expect to get hit with tickets here, here and here for approximately X hours per ticket”.

Projects requesting engineering support

Unlike production support tickets, project teams requesting assistance should be less frequent in nature.  The sources of new projects and the technical scope of new projects are a bit more challenging.  I’ve found you need a multi-pronged approach to collecting this data and it is a reoccurring activity rather than say a once a year one shot deal.  First, you need to do some digging into how your organization kicks off projects.  Is there a central PMO or Project Management Office?  Are there lines of business that have their own project management teams?  Are there product managers or customer service owners that have a project management arm that services their products and services?  Is it a combination of all the above?

For a new manager, top priority in my mind is to start building this project kickoff source of information.  It is time to break out your networking skills and track down sources of project tracking data and people who are the typical working sponsors in your organization.  Get plugged into the project leads in the PM office.  Identify product managers that typically sponsor projects that impact your team and take them out to lunch to have them spill their product roadmap or strategy to you.  Determine the budget cycle of each product your team’s technology interacts with and get talking to project leads that regularly manage product enhancement projects since they are usually tapped to offer estimates and expertise during the pre-budget cycle.

Clearly, it is possible to invest a significantly large portion of your time tracking down all these people in these various roles throughout the company … especially if your company is large.  Thus, I recommend throttling your time investment in this activity.  Step back and note if you are getting useful data or just polite conversations.  If the data isn’t flowing, it is time to change direction.  On the flip side, don’t ignore this continual time investment exercise even if investigating the feature set of the upcoming release of one of your vendor software products seems more appealing to your engineering mind.  Your mastery of knowing the technical feature set of your vendor’s products will be overshadowed by the perception you are struggling to manage the work demands on your team by your management.

The next article will dive into team capacity metrics.

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 outlined below to stop the surprises:

Step 1: Identify the attributes of your team

First, sit down and make a list of all of the request attributes of your team.  The request attributes represent all sources of work that can be said to impact your team in some way.

For a typical engineering team, I’ve identified the following example attributes:

Your Team's Work Request Attributes

• Production issue support = ad hoc requests from outside your team for subject matter expertise to assist with resolving system production issues or ad hoc “consulting” such as assisting peers with solving a problem based on your team’s expertise
• Vendor product end-of-life = vendor products that you have purchased and currently use that will ultimately reach a vendor dictated end of life date by which you can no longer get support from the vendor thus you should/have to upgrade
• Vendor product upgrades = instead of the vendor forcing an upgrade due to a product’s end of life, you may need to upgrade a product prior in order to take advantage of new features and functions, etc. you or someone desires
• Service Strategy = the IT service that you provide to the organization needs to keep up with new demands on the features you provide externally as well as the time/energy spent keeping the service functioning internally.  This is greater than just “upgrade to the latest version” but could entail workflow changes, process or procedural changes, etc. that mean some level of work impact to your team.
• Projects requesting engineering support = business sponsored projects that require some resource assistance from your team

Step 2: Build a list of sources of requests to the attributes of your team

Make a list of the sources of work requests

Proceed to go attribute by attribute and identify all of the possible sources of requests to your team.  Breaking down the sources based on similar pattern request frequency.  Using the example above:

Production Support Issues

Breakdown the high level sources of these requests assuming you provide IT services to company employees:

• Company centralized help desk

Or if you provide IT services in the form of a company product to end customers (such as a company web site):

• Company centralized help desk for employee operations group that services the product
• Customer call center that takes trouble calls directly from the end customer users

Vendor product end-of-life

Breakdown all of the vendor products by vendor, then product, then version and corresponding end-of-life date:

• Vendor A
  • Product X, Version 1.0, end-of-life = 12/31/2009
  • Product Y, Version 2.0, end-of-life = 7/1/2010
  • Vendor B
    • Product X, Version 5.5, end-of-life = 12/31/2010
    • Product Y, Version 7.0, end-of-life = 7/1/2010

Vendor product upgrades

Breakdown all of the vendor products by vendor, then product, then version, corresponding upgrade version and upgrade driving force criteria:

• Vendor A
  • Product X, Version 1.0 to 1.5
  • Upgrade in order to reduce the manual effort it takes to administer the system with the automation provided in the new version
  • Vendor B
    • Product Y, Version 7.0 to 7.1
    • Upgrade in order to get the ability to import documents in the XYZ format when the XYZ format becomes the company standard at the end of the year

Service Strategy

Breakdown all of the requests that consume time revolving around the strategic aspects of your team’s services and their associated time/resource demands:

• Yearly budget, Aug. thru Sept. yearly cycle
• Architectural Review Committee Meetings, 4 hours once a month every month
• Quarterly service roadmap presentations to senior management, 2 hours once a quarter plus 2 days each to prepare
• Vendor management, approximately 1 day per month spread throughout the month

Projects requesting engineering support

Breakdown the high level project engagement model that makes resource demands on your team:

• Yearly IT externally sponsored project discretionary IT project cycle
• Internal department sponsored projects
• IT sponsored projects that require changes in your services to support their projects goals

In the next article, I’ll take the attributes and the request sources and identify trends you can use to start building a work model for your team.

When to insert that upgrade dependency

I think one of the greatest challenges in IT is to get an IT centric effort off the ground and executed to completion.  I’ve been faced with this challenge over the years and have adapted different strategies based on the circumstances to varying degrees of success.  In this article, I’ll outline one which involves linking a sponsored project in flight requiring some technical solution from your team to an upgrade or enhancement your team wants but is struggling to implement on your own.

As mentioned in the prior article, if you are providing some IT services back to the rest of the organization, you must have some formal mechanism to aide in prioritizing the work requests.  If a project is of a high enough priority that it needs to be accomplished and your team has a role to play, consider creating a plausible dependency on meeting the project requirements via the upgrade/enhancement you want to implement.

I’ll take a stab at a typical requirements gather conversation to explain:

Project Manager: “Boss, it is my understanding that your team provides widgets that interface between the FlimFlam system and the billing system?”

Boss: “Yes and my understanding is that this project requires a widget to take the ABC format that comes out of the FlimFlam system and convert it to the XYZ format so it can be fed to the billing system, right?”

Business Analyst: “Yes, that is correct.”

Boss: “Well, I checked with my team and we have two options.  One, is we can directly develop the conversion widget in the current product version we have and that will take 20 days and there will be extensive testing and the possibility for a high number of defects due to the custom coding.  The second is we can upgrade our product to the latest version which contains native support for converting ABC to XYZ.  Thus, the 20 days becomes 1 day to configure the new product.  The new product has been out for six months and used by a number of other customers thus it shouldn’t have any serious defects.  The catch is we have to regression test the five other widgets currently in production.  Our recommendation is the second option.”

And just like that, you’ve articulated a business case that strongly suggests an upgrade you have been wanting to implement but couldn’t get all five interfaces tested and signed off.  This sixth interface project effectively completes both objectives: yours and the projects.

Hopefully you have done your homework and are seriously confident that the upgrade indeed will meet the project needs even if the “native support” is stretching the truth just a bit.  The real key is that you can realistically meet the project needs within the alternative estimated timeframe.  Once the project gains momentum and is marching down your road of upgrading and testing versus custom coding, it is next to impossible to switch the decision as long as you are trending towards meeting if not exceeding the other estimate.  One of the more difficult IT centric challenges is getting another group to test their technology that interacts with your technology when they have no reason to do so except for your need.  This approach uses the priority and urgency of this new project to drive that testing.  “Guys, we wouldn’t need you to test but this other project is forcing us to change thus we need you to validate …”

What happens if they build momentum and go against your recommendation?

The subtle power of “recommending” one particular course is one of risk ownership.  If the project accepts your recommendation, then you own the risk of not meeting the projects needs.  If the project rejects your recommendation for an alternative, then the project now owns the risk of the success and/or failure of your work to a significant degree.  How so?  Well, whenever the project comes back to complain about missed deadlines or quality issues, you have the immediate  response poised: “Well, you remember we recommended option A but you asked us to do B.  Had we done A, I believe we would be meeting your expectations.”  You have various permutations of that response as your get out of jail free card to the immediate complaint.  Clearly, if you enjoy your paycheck, you need to continue to make the project a success.  But, if the project as a whole starts trending negative, you are pretty much in the clear of taking a significant portion of the blame.

What happens if your recommendation turns out to be more complicated/time consuming than you originally thought?

This is where doing your homework comes in.  Before even recommending the upgrade/enhancement dependency option, you need to be extremely confident in your ability to meet expectations.  Going off new features and functions in release notes is a bad idea.  Working from some semi-formal product/solution testing and real engineering evaluation is a much better idea.  If your role in the organization is exceedingly intolerant of the risk failure, then I would venture to say go so far as the only open variable is the need for the formal testing signoff from the external groups.  The closed variables would be up to and including having already technically tested and confirmed the external group owned systems will work in formal testing scenarios (via the systems themselves and/or a stub of their systems touch points with yours).

The ability to link an upgrade or enhancement to an in flight project gives you the ability to help the project succeed as well as accomplish a goal on your list at the same time.  The keys are to be able to plausibly justify the upgrade approach is better than an existing solution coupled with being extremely confident based on actual testing that the upgrade will actually work.

Has anyone used this or a similar approach and had success?

How do I get this IT project started?

I think one of the greatest challenges in IT is to get an IT centric effort off the ground and executed to completion.  How many times have you been in a team meeting where the dialog went something like this:

Boss: “Anyone check out the new enhancement to the project management software we use?”

Bob the Engineer: “Yes, according to the release notes, it now includes a bug tracking module that is as good if not better than that silly third party product we use.  Plus, it is now integrated with the enterprise QA reporting service.  If we upgrade then we can turn off that third party bug tracking software and decommission the server.  Plus, all the PMs can stop manually typing in their project details into the QA reporting tool rather, hit a but to automatically populate the QA tool.”

Boss: “Sounds like a no brainer to upgrade … but how are we going to pull this off?  We need some time to install the upgrade, import the existing data, training and cut all the PMs over plus put together a training guide or something for the business testers that currently use the old testing software … plus, probably a bunch of other details I am not thinking of at this moment.”

Bob the Engineer: “Yah, this would totally help people in the company get projects done quicker without all the manual bologna that goes along with tracking stuff.”

Boss: “No one else is really looking at this but us …”

So here you stand on the precipice of a significant efficiency gain to the organization’s overall project delivery.  So why can’t you just jump on executing this obvious, no brainer improvement opportunity?  If you are part of most “MidWestern-ish” IT organizations, you have a great (or not so great, but your have one) engine for handling the prioritization of business driven requests, but lack, somewhat, the ability to inject an IT centric request.  More than likely, your current prioritization engine would drop this upgrade to the bottom of the list which means no one is going to be able to work on it given all the other high priority business requests.

I’ve been faced with this challenge over the years and have adapted different strategies based on the circumstances.  In this article, I’ll outline one which involves converting the IT request into a business request devoid of IT buzzwords.

As mentioned above, if you are providing some IT services back to the rest of the organization, you must have some formal mechanism to aide in prioritizing the work requests.  [Warning: extended water flow metaphor ahead]  It is impossible for a finite set of resources (IT) to be handling an infinite stream of requests (the business) without prioritization otherwise the organization as a whole will eventually implode in on itself.  Whether it is the example above or a new low cost storage technology or a new development language of choice major revision, one way to get some attention in the proverbial fire hose of work coming at you is to get that work into the business request pipeline.

To accomplish this, besides digging into how requests can be properly formatted to formally enter the pipeline itself, you have to start converting the IT request into a business request.  For example:

IT Version:

• Upgrade the project management software from v1.0 to v1.5
• Decommission the bug tracking software and server

Business Version:

• Enable the overall savings of $12,000 and 240 hours per quarter per IT project by providing technology and process improvements to the project delivery process, total per year savings = $480k and 960 hours less a one time investment of 200 IT hours to implement
• Supporting Data:
  • Assumption = Overall hourly rate for PM and Testing resources working on IT projects = $50 (average salary + average HR overhead + facilities)
  • Current = Averaging 20 concurrent projects each averaging 3 months in duration require 3 QA reporting updates per week consuming 1 hour per update
  • Future = Automate this process to one click, thus 20 project * (3 months * 4 weeks)  = 240 hours saved and 240 * $n = $12,000 avoided per quarter
  • [If you can compute the guestimation of monthly savings on the hardware, depreciation, software licensing and data center stuff (power, cooling, rack space, etc.) of decommissioning a server, add that to the total money savings]

Now, your first reaction maybe, “geez, those two look radically different, how can they be focused on the same goal?”  The key word in the goal sentence that I chose was “convert” an IT request into a business request.  Sure, you can look at some software release notes and quickly run through a business case in your brain that says “heck, these new features are really going to help us get work done faster”.  But non-IT people don’t immediately draw the same conclusion that you just did.  Depending on different levels of non-IT involved individuals in the project prioritization process, any number of perspectives can be drawn from the IT version:

• Why do we need to upgrade?  What we have seems to work fine
• Update = spending money … I don’t want to have to try and explain why I approved spending more money
• I don’t immediately understand this request thus it can’t be that important, next item that I might be able to comprehend …

But what are the two universal business concepts that everyone inside and outside IT can appreciate?  Doing something that will save time and/or money.

Thus, how do you get some attention and focus on your seemingly IT centric request?  Answer = convert it to a business request that somehow legitimizes benefits the change itself provides back to the business.

Anyone tried such an approach and experienced success (or failure and why)?

As much as you might want to avoid the pitfalls of estimating how long some chunk of work is going to take, it isn’t always possible.  How many times has this happened to you as an IT Manager?

Business Person <stopping Bob in the hallway>: “Hey Bob, we would like to add a simple drop down list of choices instead of that text box on the web site … how long will that take?”

Bob the Engineer: “Replace a text box with a drop down?  That shouldn’t take more than a few hours.”

Business Person: “Great, thanks for the info Bob!”

About to walk off the estimation cliff

Business Person <calling on the phone later that day>: “Sally, since it only takes a few hours to switch the web site’s text box to a drop down, can that be completed tomorrow?  We told the customers that have been asking for that enhancement that it would be ready tomorrow.”

Sally the IT Manager: “Um, err …” <how the heck did this happen?> “what about testing and who is going to populate the drop down with initial values and then add/subtract values as needed?  We don’t have a tool for that which you could use.  We don’t have a release scheduled for tomorrow and thus our Release Manager is on vacation and …” <… and now I have a big mess to sort out>

Once a non-technical person has some duration for a particular request, it is next to impossible to reset their expectations since the resetting usually involves increasing the duration with non-direct IT functions that don’t link directly to their request.  Testing?  Release schedules?  Administration?  Security?  All these don’t directly contribute to the immediate need to complete the request but are all critical to the overall quality delivery of the complete scope that the request dictates.

The first challenge to avoid these scenarios is to coach everyone on your team that they must never ever give out any work estimate of any kind unless you have empowered them to do so.  Make them comfortable with side stepping the artificial urgency of the request with uttering phrases such as:

• “I am not sure.  Can you send me an email with the request so I can track down an answer for you?”
• “I don’t know all the details.  Can I get back to you with an answer?”
• “I am not sure but I think I know who does. Can I get back to you with an answer?”

In my opinion, the best is some permutation of the first option which asks the requestor to write down, i.e., do some work on their part, what they want and send it along.  I am continually amazed at how many verbal requests with urgency never become written requests when asked to be submitted as such.  They couldn’t really be urgent if it takes all of five minutes to craft a quick email with what you just asked for in it and send it along.

In a follow-up second part to this pitfall avoidance I’ll suggest a format to reply to work estimation requests with “CYA” coverage.

Anyone have any other tried and true methods to show responsiveness and concern for a request yet channel the request into some mechanism to respond rationally and with appropriate “CYA”?