Midwest IT Survival

Are Corporate IT Patents the on the Rise?

Many times in the course of a corporate IT project, new and innovative technical solutions to challenging problems are developed. Many of these solutions are related to the hoops one has to jump through to get company specific legacy systems and legacy decisions to integrate with new technical products or capabilities. Thus, are these solutions truly innovative? No, most are not if they are viewed in the context of “from outside the company”. “Inside the company”, they could be a miracle of cross-team, cross-department partnering and vendor product limitation mash-ups. “Outside the company” observers would be wondering why such a convoluted approach was needed for a seemingly simple interoperability challenge. Yet, every once in a while, a technical approach to solve a problem that isn’t truly unique to that company occurs.

Geez, IT is so mature these days one has to wonder why there aren’t fifteen vendors clamoring to demonstrate how they can solve these problems with their products. The vendor landscape either hasn’t recognized that their customer base has a problem they can sell a solution for or the problem is created by vendor solutions that provide a core capability but don’t go the last ten feet to cross the finish-line of a fully mature feature set. With all this being said, the question that seems to be coming up more and more is:

Is that innovative corporate IT technical solution worth getting patented?

My first thought that always comes to my mind in these discussions is:

Why is it worth it to patent something corporate IT-ish when the business’s core competency isn’t delivering IT products and services?

It is easy to understand why, say, Apple, Google and other tech companies are rushing to patent new and innovative techniques such as in the mobile device functionality space. The monetary compensation surrounding having to pay a competitor licensing fees means you win, revenue-wise, when your competitor sells a large number of devices. Imagine if you were the patent holder of something used in the Apple iPad 2. If you licensed that invention to Apple for a mere one cent per device, in the fourth quarter of 2011 alone, you would net $154,000.

Thus, it seems that corporate IT does not get to generate direct revenue through patenting solutions. So why do so? The strategy here appears to be one of investing in a solid defense as opposed to an aggressive offense. That defense appears to be at least two fold.

Vendor Leverage Reduction

Vendor products are so pervasive in corporate IT it is next to impossible to avoid the sometimes painful contract negotiations. I’ve written quite a bit about the corporate IT management/vendor relationship in the past in a series starting here. If a vendor becomes aware you are using your own approach to a solution they have patented, the company can lose significant leverage in the contract negotiations as the raw legal sparing can trump the best sales/customer relationship. These negotiations can turn even worse if the company is trying to switch to a competing vendor.

Non-IT Company Product Battles with Competitors\

More similar to the classic tech company patent wars such as between Apple and Google/Motorola, non-IT based companies have similar legal battles over non-technology product patent infringements. In addition to holding the non-IT patent, having an additional IT-centric patent that complements the original product patent infringement helps strengthen the case of that patent holder. Thus, not a clear cut win for the patent holder, but clearly a legal strategy to make the claimant have to invest in an even larger, more expensive and time consuming case.

So, can everyone expect a rush to apply for patents for innovative corporate IT solutions in non-IT centric companies? I wouldn’t say rush, but as technology become an ever more important and strategic component of traditionally non-IT centric companies, look for a steady increase in patent applications as part of a holistic business strategy to be in a strong position to go head to head with a competitor in a patent infringement suit.

Today's IT Projects Need Transparency to Change

For large organizations it seems that as technology grows more and more integrated, IT related projects become more complex and thus longer in overall duration. There is no doubt the rise in cloud/SaaS solutions has exacerbated this increase in overall IT project complexity. I’ve written on the impact of cloud in this manner prior here. Gone are the days of a large corporate IT shop having a project manager engage the same three or four familiar delivery stakeholders and with little outside involvement, execute the project beginning to end. This increase in technical integration means a project manager can no longer count on those three or four stakeholders having the cross systems knowledge and technical systems access to implement changes as crisply with few artifacts as to what the project has done/is doing/when/etc.

To help illustrate this evolving shift, consider the following hypothetical large corporate IT conversation:

PM: “Welcome everyone to the FlimFlam upgrade project’s twentieth weekly status meeting and a special welcome to Jim who is joining to help sort out all the changes that impact others outside of our core team.”

<General welcoming gestures and verbal niceties ensue>

Jim: “Ok, is there any diagram that captures all the flows of data in and out of the current FlimFlam system?”

Core Team: “Um, no, we just know them from working on FlimFlam for the last five years.”

Jim: “Um, ok, have you mapped out what new features of the upgrade are turned on compared to off and who would be affected? Or say, documented the link between the features and business requirements?”

Core Team: “Well, not documented, but we know HR wants the real-time instead of batch interaction and Operations wants better reports. But HR outsourced last year to a cloud provider and we have no idea what Operations is doing …”

Jim: <thinking to himself> “… oh boy, good people, but this project is looking like a train wreck already …”

Clearly a “business as usual” approach to this upgrade isn’t going to work any more.

In the past, with so few stakeholders having comprehensive access to the silo-ed systems impacted by these types of changes, the need for easy to digest transparency into what changes were going to happen when and how was not critical. Sometimes the only visibility to what such a small project team was doing was in the production change management review and approval process:

Change Control Board: “Ok, next up is change record number 72,578 which reads ‘Enable the employee web portal to support the time off calendar’. Anyone here have any concerns with this change? Hearing none, approved. Next on the list …

Today’s Problem: IT systems are too interconnected for lack of project transparency to change

Sounds like 72,578 is a simple change that an HR delivery team of the past could have easily implemented without much cross team impact. But today, that example time off calendar may need to interact with the HR system to record those time off days against how many the employee actually has as part of their compensation package. There probably is a need to support some management approval work-flow. Plus, there are probably other work scheduling systems and PMO resource planning tools that need a feed of that data in order to accurately support their user base. There is probably some single sign on/web access management technology involved to support all employees accessing the web portal, some central provisioning system to handle access plus some remote access needs to support today’s mobile workforce. It is probably safe to assume that some of those integrated systems are in-house and some are cloud/SaaS or a mix of all of the above.

Additionally, with matrix-ed internal and external project resources with contracted and off-shore delivery coupled with the “cloud” vendor resource engagement model, a simple change could have a variety of stakeholders in need of agreement on what is changing when, etc.

Thus, hopefully I’ve convinced you that something as simple as a web portal for employee time off entry can involve a number of different internal and external teams and systems that all need to coordinate changes to support the business objectives of this example project.

So how does this all drive the need for “transparency”? Isn’t this just a basic PMO 101 issue of dependency management and cross project impacts?

Yes and No

The project team needs to produce deliverables that don’t just get the core team in agreement to pass the next quality gate in the project life-cycle (never to be revised again); the project team needs to produce deliverables that outline, at a high-level, the following basic project elements:

• Scope of the project in a sentence or two
• What is changing from present to future state
• Who is impacted by the change (and have they been engaged)
• Lastly, what isn’t in scope (that a non-core stakeholder might assume is in scope)

… for non-core stakeholders to easily digest and understand … and update the material frequently to have at the ready anytime it might be needed.

Besides an effective communications vehicle, another subtle yet important aspect to this deliverable is its ability to build confidence in the effective management of your project in outside stakeholders. This confidence can lead to senior management getting the impression the project is “under control” and move on to another project for increased scrutiny rather than assigning all kinds of ancillary people to dig into your project to figure out why they don’t have that “under control” feeling.

Stated another way, large corporate IT projects today need to adopt a bit of “program management”, specifically, some of the enterprise reporting themes. A Gantt chart (which I’ve extolled the benefits of before here) isn’t the end-all-be-all here. A slide deck that contains a few slides covering these topics with lots of pictures and drawings where ever possible would be more effective in serving this communication need.

So if you are a project sponsor or a project manager, consider having a communication deliverable that is actively maintained, even if your PMO PLC doesn’t explicitly call for one, to provide simple and easy to digest transparency into key aspects of your project at the ready at all

Produce a Business Case Deliverable

In the first part of this series on senior management communication for those more comfortable with grep-ing an exception log or tracing through lines of code to find that elusive bug the conclusion was:

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

In the second part of this series, we used an example of engineer Bob recommending his company invest some cash and resources into an operating system upgrade. The initial logical conclusion that a sequence of facts surrounding how awesomely technically cool the new OS is would convince anyone to make the investment. Yet, spewing facts isn’t as compelling as it is to:

Relate the facts and figures to senior management’s goals/vision

To do this, structure a presentation into a story following this sequence:

1. Describe the Current State including gaps/challenges/issues/problems
2. Describe the “Optimum” Future State
3. Describe the Roadmap to get from Current to Future State
4. Outline the immediate next steps to get started on the Roadmap
5. Throw anything ancillary or supporting to the above 4 steps in Appendices

In the Bob’s case, consider “telling the story” of ultimately what aligns to senior management’s goals/vision in this example context: computing capability at reduced cost.

Using the above sequence as a template for Bob:

1. Current State

• Number of servers running prior OS, server count over time
• CPU utilization
• Maintenance costs (total cost of ownership if it can be computed, support contract costs)
• Indicators when “bad news” like special support contract costs, etc. show “doing nothing” is a negative
• Intersection with any other projects that need capabilities provided by your Future State

2. Future State

• All servers running new OS phased in over timeliness
• CPU utilization
• Maintenance costs

3. Roadmap

• Upgrades broken into simple chunks
• Chunks representing some useful grouping (rather than random)
• Testing or other functions supporting the upgrade
• Costs over the duration

4. Next Steps

• $$$ approved to buy hardware
• $$$ approved for 2 resources
• Initial steps within your organization to get a formal project going

5. Appendices

• Data showing why 2 resources are needed, what happens if you get 1 or zero or 12
• Any other data, facts, figures around “hot button” issues that might come up like a trend to out-source or in-source work, strategic vendor partnerships, etc.

Your goal in telling this story is to have a compelling deliverable in the form of your presentation that conveys to anyone that it would be just plain silly not to execute your roadmap. That “anyone” needs to be both technical and non-technical people. I am certain your technical peers are going to be 110% behind anything that involves implementing new, cool technology. What techie holds the position of “nah, I still want to be a Windows 98 shop.” At the same time, the more holes that can be poked in your analysis the more likely your great idea is going to get trampled by the masses and not acted upon.

Sure, others might suggest not putting this much effort into a request that “should just stand on it’s own to support action”. A recent (how timely!) tweet from @rands suggests as such:

And although it might seem highly desirable to be able to convey your technical request in words and have immediate understanding and support, those veterans of large corporate IT shops know there is a big complex organization with overlapping, competing and sometimes contradicting priorities that can easily mount a campaign against your plan. Thus, those quick to dismiss the value of a slide deck deliverable in corporate IT might be missing a critical element of this series: producing a deliverable.

Sure, once you have a deliverable out there others can still mount a defensive. But, you also empower your management with a strong case to move in your direction that can be forwarded along and forwarded up. The more compelling your story, the more it stands on its own as a viable business case to make a strategic company investment the more the financial/business minded in IT will be able to comprehend and support your plan.

So, before you write-off the value of putting the effort into crafting a story deliverable that compels the non-technical decision makers to act on your plan, consider the alternative: a verbal request to spend money on some cool technology? If you are planning to invest a significant portion of your own money, do you want to buy some cool technology or act on a strategic technology investment with data backed returns?

Convincing senior management of technical direction requires new communications skills

As a server administrator, you invested in knowledge associated with configuring operating systems to perform optimally and be able to interrogate error logs to diagnose and report problems efficiently. As a software developer, you sought feedback from code reviews and combed forums and blog posts and (depending on when you were in this role) books to improve your code. In your role, you invested in the technical skills that expanded your ability to deliver solutions within your respective discipline.

Being measured on skill-set attainment wasn’t particularly evasive. Your servers were deployed live and they either performed their needed functions in support of applications and end users or they crashed after deployment with a flurry of functional issues reported to the helpdesk. Your code either met the functional requirements and was bug free after being tested or defect reports mounted. There was more direct feedback as to what skill-sets you have mastered and what areas of your respective discipline needed more investment.

Even communicating to your direct manager in these technical roles provided more instant feedback as to your ability to successfully articulate problems, issues and recommendations for improvements due to the frequent interactions between yourself and your manager. And from your manager’s perspective, they were tasked with delivering a service and needed you to execute tasks to meet commitments.

But what about communicating to senior management?

In most cases, you are not directly interacting with senior management on a daily or even frequent enough basis to build implicit trust. You can rarely walk blindly into a budget meeting with senior management and say:

“We need to upgrade all the servers to RHEL 6. In order to do that we will need to buy ten new servers at X dollars each for a total of Y dollars now and we will need two more people to build and swap in all those servers. Of course, we’ll need all the applications to test after each server is re-built. And …”

with senior management responding with:

“Sure Bob, let me get out the checkbook …”

It is almost painful to observe a solid, technical individual attempt to explain a technology need to senior management who hasn’t determined how to effectively communicate that need in a format that senior management can more readily absorb. Equally troubling is seeing a poorly communicated yet real technical need be decided against by senior management based on a weak presentation. You can almost predict the conversation that will happen some number of months later:

“Bob, how come we have to pay this huge support contract on our servers? How come I didn’t know about this earlier?”

“But Sir, I tried to tell you we needed to upgrade our servers before …” This conversation becomes more awkward with each subsequent exchange.

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

So, what steps can one take to make this investment in their communication skills? For one who has focused on learning technology, the shift of focus to learning effective communication skills may seem elusive at first. Thus, consider spinning up a thread in your brain that breaks this down into a logical exercise.

Look for part 2 of this article to dive into some logical steps.

Project sponsor turnover can be handled smoothly

Hallway conversations and whispers in meetings have the grapevine quickly communicating the departure of a highly visible person in the corporation. “Did you hear Bob gave his two week notice?” “Yah, any idea where he is going?” “No, I don’t think he shared that.” “Who is going to lead the big FlimFlam upgrade project now?” “Don’t know that either. It hasn’t been announced. Bob has been it for as long as anyone can remember.” “This could get very messy.”

I was reflecting on my participation in a large, multi-track, multi-phase, multi-year project some time ago. So, safe to say, this was a big project involving substantial change across a variety of technology groups, products and business units. About a third of the way through the project, the day to day business sponsor left the organization for an outside opportunity. Since the project was well under way, being a third completed, a new sponsor was needed to step in quickly to keep providing direction to all the concurrent work streams.

Executive Leadership Steps In

The executive sponsor immediately started attending the regular program level status meetings. This provided much needed leadership. Thus, two big thumbs up for her participation. Instead of everyone looking around the table at each other wondering who was in charge, there was continuity in project leadership.

New Sponsor Arrives

The executive sponsor didn’t waste much time sourcing a new business sponsor for the project. With only a few weeks of drift, a new day to day sponsor was at the table. The executive sponsor gave a brief introduction and the new sponsor took charge. Following the introduction, it was clear to everyone that the new sponsor wasted no time getting up to speed even though he had no prior knowledge of the project nor subject matter expertise in the goals and objects of the project itself. The new sponsor already had had meetings with key stakeholders individually.

New Sponsor Sets the Tone

The new sponsor also gave brief summary of the current state of the project, the major open issues and summarized the strategic next steps. In summarizing the next steps, the new sponsor established an immediate credibility as the prior sponsor seemed to be struggling a bit with how to prioritize the cross-functional team’s focus for the in-flight work streams. All in all, the new sponsor, in the first formal meeting, established a strong confidence that had everyone leaving that meeting with a positive sense of enthusiasm that we were all in good hands for the remaining work ahead. The new sponsor clearly set the tone for project success.

So what made this potentially negative situation result in a re-energizer to the project team?

• Executive leadership presence immediately upon word the current sponsor was leaving the organization.
• Executive leadership remaining visible and actively engaged through naming the new sponsor.
• The new sponsor’s strong initial engagement and clear understanding of:
  • Project’s current state
  • Clarity surrounding open issues
  • Ability to articulate next steps.

Has anyone else experienced a positive project sponsor change? What contributed to the success of the leadership switch?

How do you survive without SMART goals in today's Corporate IT?

There are plenty of great resources on the Internet that offer excellent perspectives on management and leadership that can be readily applied to those working in corporate IT. And one would think with the vast amount of excellent free advice, all managers would excel at their jobs. Alas, today the demands on IT management make readily putting that advice into practice exceedingly challenging. Recently I’ve been contemplating on how to best articulate what I feel is the dichotomous role a corporate IT professional has in today’s workplace.

Dichotomous Role:

1. Deliver on what your manager of the moment expects
2. Deliver on what your role is expected to deliver to the organization

Why “dichotomous”? More often than not, what your manager expects can be incongruent with what the organization expects.

One might think all you have to do is understand your job description, your department/team/personal goals and objectives and go off every day and do your job. And for some they maybe enjoying this straight forward, obvious job function clarity. But for most, I would feel confident in saying that seeking this expectation clarity can consume a significant number of brain cycles everyday with varying degrees of success. Frequently, your manager’s expectations differ with what the organization expects. What forces are at play creating this dichotomy and what can you do to stay sane over time?

Biggest Contributors to Role Dichotomy? Lagging Goals + Manager Shuffling

First, Lagging Goals

I know of no study or statistical evidence to support my claim, but I feel rather confident in saying that the rate of change in IT has increased dramatically in recent compared to prior years. Step back and take a sample of recent IT management articles. How many are asking the CIO role to change? How many are saying you have to have a mobile work force, outsource development or leverage “the cloud” or risk falling behind? With all that rapid change, in my opinion, pragmatically, gone are the days of SMART goals. Recently, Pawel Bordzinski posted an article similarly calling SMART goals into question here. Sure, MBA academics and management blog pundits will tout the benefits of clearly articulated goals leading to reports having increased delivery success and improved job satisfaction.

Let me be clear up front; I am not contradicting the sound fundamentals of solid goal setting. But unfortunately, with corporate fiscal cycles starting/ending and thus “trickle down” goals trailing six months or more from the cycle start, the average corporate IT employee is lucky to get written goals if they get any goals at all. In looking back over my last five years I probably can point to only two situations where I actually was given documented goals for my job role. In both cases, the fiscal year had already been underway for a good five or six months before I got those written goals.

Why the lag in goal delivery when all sound management principles suggest timeliness equals improved organizational success? In a phrase:

The current corporate business climate expects IT change at such a rapid rate that lagging goals can’t easily, if at all, keep up with the organizational change and subsequent overlapping vision changes.

These typical corporate IT scenarios may seem extremely similar to many and they help illustrate my point. Consider how established goals would need to be handled in each case:

1. The company hires a new “chief marketing officer” who has a new chunk of budget to spend on a “mobile strategy”. Suddenly, new IT projects are kicked off to deliver mobile solutions.
2. An IT Director of the “something” department retires and a new Director is hired from outside the organization. Managers reporting to the previous Director either start reporting to new areas of the organization or start leaving the company. The new Director starts hiring replacement mangers from his prior company.

In the first scenario, assuming managers, teams and individuals had goals that reflected pre-CMO priorities, all now have to wind down a bit on what was previously being worked on and wind up on what the new CMO sponsored projects entail. Sticking to pre-CMO priorities are just not an option. The company clearly has a strategic gap hence the CMO was hired in the first place. Thus, ignoring the CMO’s “high priority” projects because they don’t fit nicely into prior communicated priorities and goals is effectively ignoring the business needs of the company.

In typical corporate IT fashion, the priority of these new CMO projects has been communicated from the top of the house down thus the entire IT delivery management structure is trying to figure out how to reshuffle in-flight work in order to accommodate them. The crisis of the moment has shifted from whatever was the previous crisis to the new CMO project delivery crisis. The company wasn’t strategic enough to see the need for a CMO earlier as new media outlets were creating new demand, what is to say the organization is strategic in addressing new IT project priorities? Lastly, with IT departments cut staff and budget-wise due to the recent recession, what management structure is going to stop and revise all previously documented goals? The demand for flexibility, agility and rapid change makes it next to impossible to be able to cleanly re-write goals as priorities shift.

If the goal setting challenge faced a stagnant organizational chart, then there might be some HR efficiencies all could leverage, but on top of priorities changing, org structures rarely stay static for more than a few months. The second part of this article will dive into what compounds the goal problem for corporate IT employees: rapid organization and management reporting structure changes.

Earlier this week I was given the opportunity to share my “aha moment” when it comes to project management.  Below is a brief quote from my article submission:

“Like it or not, technical people need project managers. Yet, ask the average software developer, systems integration engineer or infrastructure engineer about what their company needs more of role-wise and they will almost without a doubt say: “We need more X’s. I’m buried in work!” Feel free to replace “X” with whatever job title applies to whom you are questioning. Software developers indicate they need more developers because the product owners keep asking for more features faster than can be developed.”

Feel free to read the article in its entirety here.

"I just signed the sales contract yesterday. This needs to be up and running by the end of this week!"

In talking to others recently, we’ve discovered an unfortunate pattern across multiple companies where the partnership between the business units and IT isn’t particularly strong. When I say “partnership” I mean the level of collaboration on business activities that involve IT in some manner. Prior to contracts being signed, has IT been directly involved in the new business opportunity? Does IT have a voice in the major initiative delivery date setting process? Is IT’s resource capacity considered at the same time the business’s resource capacity is being evaluated in moving forward with a major effort? Does IT have access to the business’s multi-year plan? Are IT initiatives peppered throughout that multi-year plan?

There are a seemingly endless list of articles available on the Internet that talk of the need for a strong partnership between IT and the business units IT supports thus I won’t extol those benefits here. Rather, what can an IT manager do in a company that is taking strides towards but is still working on forming a strong business and IT partnership? Or …

What to do when the Business wants “Instant IT Gratification”?

By “Instant IT Gratification” I mean the corporate culture where IT is expected to delivery what the business is asking for, how they are asking for it and when they want it done all without collaborative dialog. Contracts are signed without IT. Due dates are determined in advance and IT is expected to meet these deadlines without being consulted. The results of such interactions between IT and business requesters varies, but the thematic results are the most frustrating:

• Sub-optimal technology implemented: Instead of matching the need with the optimal technology, the quickest/fastest must be chosen to hit the date.
• Many post-deployment follow-up activities needed: Instead of having a healthy collaborative discussion about all the “requirements”, only what the business shares is implemented requiring many “oops, we forgot we also need X”
• Inability to upgrade/enhance existing technical capabilities: always focusing on the urgent needs of the business without allocating a percentage of time to invest in more current technology assets.
• Work never done: Constantly jumping to the next hot request leaving only phase one of Y implemented from the previous hot, now cooling request.

What can an IT manager do in this kind of culture?

Anyone who skimmed the above bullets and identified with even one point knows these are cultural problems that a single IT manager won’t be able to solve over night. So how does one not pull their proverbial hair out of their head trying to get anything proactive accomplished in such a re-active business model? Consider some of the options below; just know that none is a silver bullet of success.

• Leverage the formal charge back model.

If your organization has a formal IT work charge back model, become intimately familiar with how the process formally and informally works. Employ the charge back model in every possible situation to ensure there is fully accountability and record-ability for all business requested IT work.

• No formal charge back model, then use time as the “IT currency”.

If no formal charge back model exists to leverage, then the only real charge back model or IT “currency” is time. Make sure you have full data based reporting on all the work your team is performing. When a new “hot” request comes in, update your single view of the work and present the new “hot” request alongside all the previous “hot” requests and ask the business to prioritize.

• Like it or not, get some formal work estimation model in place

If all the business requests “just get handled” then the business has no governor for making requests. Without a charge back model to where the business has to make the conscious decision to spend on one thing compared to something else, there is no barrier for the business to make every conceivable request to IT. One approach is to “just handle it” and try to service every request as quickly as possible so to not have to engage in any prioritization or work break down discussions. But as I have written prior, having some formal work estimation process allows for an intelligent, data and date based discussion with the business. When presented with duration and possible delivery dates, business users can more easily take low priority work off the request list. Low priority work can easily be removed once it is known by all what is consuming time and delaying the delivery of what the business truly needs in a hurry.

• Don’t blindly start working on requests, ask probing questions

From a previous article on my learning in attending a formal Agile training class, asking why multiple times (per the instructor, ask “why?” five times to get to the bottom of the need for a request) in order to dig into the real reason for making a request for work to IT. You will be amazed how many times the request hasn’t been fully vetted by the business. Asking why to get to the real business case to support a request will help to reveal what is truly a priority that IT is in the best position to deliver on compared to a frivolous request that if not executed, actually reduces technical debt without harm to the requester. Invest 40 IT hours in order to avoid a situation that happens maybe once a year and consumes 4 hours of the business’s time? Assuming all costs being equal between the business and IT (usually IT costs more per hour) , a ten year return on investment? It would seem those 40 IT hours should be invested elsewhere.

As I said, these clearly aren’t silver bullets that eliminate the challenges of a less than strong partnership between IT and the business units. Yet, by consistently improving ones capability to work with business requesters through careful implementation of the bullet points above, one can establish a level of credibility for your team’s services back to the business to better align the limited IT resources with the highest priority work for the company as a whole.

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”.

Is everyone at the same level of competency?

As I was trolling through my RSS feeds of blogs I try and keep current on and I ran across another thought provoking post by Todd (@backfromred) entitled “The Failure in Gating Process”. I wrote a brief comment to share with Todd and his readers. In the comment I stated that I both agreed and disagreed with Todd’s premise. This blog article expands on that conflict.

Todd’s premise is that having PMO enforced project gates:

• Interrupt project progress momentum
• Allow management and sponsorship stakeholders an excuse to zone till “quality gate #4 next month” before paying attention to the project
• Efficiencies lost to stop, starting and context switching

It is difficult to argue that gating process or projects does have a “cost” associated with the stoppage.

Todd’s solution is better stakeholder engagement.

Again, I can’t disagree with his solution in theory. Where is disagree is in the practical implementation of “better stakeholder engagement” in the real world. First, project teams need strong, competent and knowledgeable participation from these disciplines:

• Project and Executive Sponsorship and Prioritization
• Project and Program Management
• Enterprise and Application Architectural Alignment
• Requirements Gathering, Documenting and Tracking
• Business/Systems Analysis
• Vendor Management (if 3^rd party providers involved in solution delivery)
• Technical Development/Integration Leadership/Delivery
• Testing (from unit through final business acceptance)

Simply having resources “engaged” from these disciplines does equal success if the engaged resources lack competency in their discipline and/or knowledge in their discipline to bring into the project fold.

How practical is it to have strong, competent and knowledgeable resources on every IT project in your portfolio?

I argue it is rare and even if all those resources exist in the same organization, they are assigned to the highest priority and visible project(s) alone. This leaves mid to low priority projects with a less than optimal resource mix.

How do you get timely visibility into when a less than optimal resource mix staffed project team is trending off the optimal trajectory?

You need a project gating system applied to specific projects to strategically pause, evaluate and course correct those specific projects.

I chose the previous statement’s phrasing carefully and specifically to avoid claiming that having a default project gating system as a “silver bullet”1 is the answer. Again, I’m not arguing against Todd’s claim that better stakeholder engagement is needed for successful IT projects. I’m saying the practical application in the real world still requires a project quality gating system due to the inability to have strong, competent and knowledgeable resource.

I have some thoughts on attributes of a more efficient project quality gating system, but I think I’ll need another article to collect and share these thoughts bouncing around in my head.

1. Top notch blog publisher Peter Kretzman on his blog “CTO/CIO Perspectives” has an excellent article on IT “silver bullets” and how to get early indications of projects in jeopardy.