Apply positive agile development roadmap practices in your organization

By Rick Freedman

Takeaway: The view of agile development as a simple methodology shift is a predictor of failure, according to Rick Freedman. Read his four tips on applying positive agile roadmap practices.

I mentioned in a previous post that the current “word of the month” in the agile community is “roadmap.” Let’s explore the idea of the roadmap a bit more and see why it has captured the imagination of the agile community. To do so, we need to ask a fundamental question: Is agile development a methodology or a philosophy?
I ask this question because many of the clients I meet in my training and consulting practice seem to see agile adoption as a methodology question. “If I can just get my PMO to use burn-down charts instead of Gantt charts, and to substitute daily standups for weekly task review meetings, I’ll be agile!” Unfortunately, my experience is that this view, of agile as a simple methodology shift, is a predictor of failure. It frequently goes together with a lack of management buy-in (”our managers don’t care what methodology we use as long as we deliver projects!”), lack of team training (”we’ll train the PMO and they can enforce the new standards!”), and, in the context of this discussion about roadmaps, lack of an overall guiding vision of both the migration (”why are we migrating to agile?”) and the project portfolio.
I often see agile trainers who unfortunately promote the methodology view of agile. They focus their training on the techniques and protocols, such as daily standups and scrum or kanban boards, and give short shrift to the strategic and “vision” elements of development. I agree that there’s merit in the philosophy that says new agile teams should hew closely to the known practices of scrum (or whatever their chosen approach), rather than starting their agile journey by making up their own set of techniques. I resist, however, when this becomes a process-driven exercise, in which the application of strict scrum practices is emphasized above the core values of collaboration, self-direction and, above all, individual accountability. The process adds value, but it’s not the process that drives results, it’s the people and their interactions.
Why am I digging down into the philosophy of agile in this conversation about roadmaps? The risk of a methodological focus in agile migrations is that the organization can become expert at the techniques of agile development while still missing the point of their development efforts. As depicted in the well-known Version One agile poster, agile development consists of a concentric set of planning activities, all of which are reliant on the strategic plan that drives the organization’s development efforts. Said more simply, without a roadmap, we may be great drivers but we don’t know where we’re heading. In an innovative culture that’s inventing something new, exploring the scenic byways is often an important element of our creative process, but, even in those circumstances, having a general roadmap that calls out the opportunities we’re trying to exploit and the possible endpoints we visualize can help focus the team’s energies.
Before we get to the user stories and the release planning, before we map out the iterations and the individual responsibilities, we need to build consensus around a roadmap that defines that vision and strategy we’re pursuing. I often draw the distinction here between the traditional style of strategic planning, in which only senior managers are invited to a closed door or off-site meeting, and they often return with a set of “sacred scrolls” that outline the enterprise’s strategic direction and high-priority initiatives for the next year or two, and the all-hands, iterative, and facilitated exercise that constitutes an agile strategy workshop. I’ve seen too many strategic off-sites that produce an unprioritized wish list of hundreds of initiatives, with no clear over-arching strategic purpose other than scratching the itch of each department or manager. Without an understanding of the strategic meaning of these programs, implementers (like the IT department) struggle to understand where they should be focusing their energies, and projects end up selected due to political clout or technical familiarity rather than strategic importance.
After all this talk about what a roadmap shouldn’t be, how can we apply positive roadmap practices in our organization? Here are some observations from my consulting work with high-performing agile teams:

• Roadmap planning is inclusive: The old model of strategy as an exclusive club where senior managers only are invited is dead. The core values of agile teach us that innovation requires collaboration and self-direction; this doesn’t apply only at the tactical, methodological level but at the vision and strategy level as well. Invite the IT teams, the developers, the rank-and-file business “do-ers” to the table, and develop strategies that actually resonate team-wide and have enthusiasm and commitment behind them.
• Prioritization means selection and sacrifice: Prioritizing efforts for investment and resource is about more than a stack-ranked list; if that list includes more projects than the team can possibly achieve, and lacks the support or understanding of the developers, it typically results in death-march projects with unrealistic and arbitrary deadlines, and lackluster efforts by uncommitted developers. We all know we’re not going to complete 165 projects this year; let’s stop fooling ourselves and do the heavy lifting of selecting the small number of real impact projects, and of getting the organization to agree on those and commit, not just dollars, but passion, personal accountability, and reputation on their completion.
• Predict but don’t prescribe: Persuasive roadmaps draw a broad picture of how the strategy will evolve, often describing the features and opportunities we hope to tackle in the first release or current year, and then, in gradually less specificity, define the general direction in which we hope to move the initiative. Good agile planners understand that, the further out we look, the hazier the picture and the more likely changing realities will drive changing priorities, but they also understand that a complete vacuum of planning creates confusion and saps commitment. On the other extreme, agile strategists need to ensure that general roadmap exercises don’t become estimations; especially in traditional environments accustomed to long-range estimates, stakeholders often try to turn vision exercises into “over the horizon” cost and schedule estimates.
• Share the vision: Good roadmaps don’t just tell us where we’re going - they tell us what waits at the end. Too many traditional strategic plans look like an update of the original business plan - dry, uninspiring, and written for accountants and bankers. Good roadmaps are marketing documents as well as strategic plans - they convince and persuade the enterprise that each selected program is worth doing, will bring defined benefits, and will reward the extra effort by improving the business and our business life.

I’ll talk more in my next post about the relationship between roadmap development and estimation. Stakeholders, PMOs, and project managers accustomed to the “triple constraint” theory of project planning often want to proceed directly from the roadmap to a detailed work breakdown structure and project estimate; I’ll discuss how we can help them understand the commitments we’re making without getting tied down to an un-knowable estimate.

Read More

Six things your IT department should stop doing today

By Scott Lowe

Takeaway: Scott Lowe identifies six activities that he thinks should be handled by others or through different means.

Many IT departments started out with just one or two people who had to become jacks of all trades and get their organizations slowly up to speed with the rapidly changing face of information technology.  As times have changed, the nature of the work has changed, too.  Many of these IT groups of old are now much larger and handling mission critical systems that keep the business running.  While there are still some of these one man shows out there, even they have to make sure that they’re focusing on activities that run the business and not on items better handled by others.

As I’ve traveled in recent months, I’ve had the great opportunity to see a lot of different IT departments in action.  Many that have “grown up” organically still cling to some activities that they should consider moving off to other people.  In this article, I’m identifying six activities that I’ve seen in action in IT departments in recent months that I think should be handled by others or through different means.

Running and making cables

When I started my very first IT job back in 1994, one of the first projects I was placed on involved running category 5-state of the art at the time-cabling through K-12 schools and terminating that cable to either a patch panel or by crimping an RJ45 connector on the end.  Because Cat5 was so new, it was still pretty expensive, so my organization opted to make many of our own network cables, too.

Today, this is an activity better left to people who specialize in cabling installations.  The value-add to the organization for making a network cable is, most likely, negative (as in, it costs more to make than to buy when you consider time and materials) and there’s no guarantee that it will work.  I remember spending quite some time learning how to terminate both Cat5 and thin coax and, today, am thrilled to see organizations that bring people in that have the technical knowledge and testing tools necessary to install cabling that conforms to requirements for ever-more-sensitive networking electronics and standards.

While having someone come in and install cabling will cost a bit of money, consider the opportunity cost side of the equation.  Is there an activity that your IT department could be doing that has a more substantial impact on the bottom line?  Start doing that and stop doing this.

Creating accounts manually

First of all, this one can be hard to do, but it’s so worth it in the end.  How much time does your staff spend managing accounts and dealing with exceptions?  Don’t forget all of the ancillary tasks that come along with creating an account, such as provisioning a mailbox and creating a home directory, among other things.  As you add more systems to the mix, this job becomes more and more onerous.

Here’s the rub: User accounts, for the most part, can be completely driven from other systems, most notably the human resources system.  Implement identity management tools that can be programmed to take the hassle out of this activity by mostly automating the process.  From there, IT has only to handle exceptions and any specialty accounts that may need to be created, such as service accounts.

Servicing printers

Quick poll… how many of you hate supporting printers?  If you’re a typical CIO, printers are the bane of your existence.  They cost a lot, they’re finicky and users prize them and scream when they aren’t working right.

Here’s what I did.

I made it someone else’s problem by moving to a managed printing service.  The company selected assumed full responsibility for all of our existing equipment and provided both repair services and toner replacement.  In return, we paid the company per page printed each month.

Believe it or not, we saved a lot of money.  The company could get parts more quickly and easily that we could and their bulk buying capability got them toner at prices we would never have been able to touch on our own.  Best of all, it freed up scarce help desk staff time to focus on other needs.

Taking a “build first” approach

There was a day when building software was the only way to get something done for the business.  Of course, organizations have always performed a build vs. buy analysis, but today, with the rise of cloud services, organizations should be leaning to the “buy” side of th equation.  I say “leaning” because a buy approach will not work for everyone in every situation, but it makes sense to see if your business problem has already been solved by someone else before you start coding.

Manually installing software

Microsoft will be releasing a new version of Office in the coming months.  How will your organization do the upgrade?  Will IT staff run around and install the upgrade from a central network location or will you push the software out using an automated software installation tool, such as the one included in System Center Configuration Manager?

As is the case with some of the other very repetitive, non-value add activities discussed in this article, routine software installation should be handled as a part of an overall imaging process coupled with a reasonably robust software distribution platform.

Resetting passwords

Statistics show that password issues are a healthy percentage of help desk calls… but in an unhealthy way!  When a user has a password issue, they can’t do their work and the IT staffer is taken away from what could be more important work to handle what could be a self-service task.

Self-service password reset tools can be had for really cheap these days and can be implemented, literally, in a day or two for smaller organizations.  It might take a bit more time in larger organizations, but it’s still not rocket science.  I recently implemented self-service password reset at one of my client sites.  The tool was relatively low cost and even had a way to integrate with Windows login screen so that the user could reset his password even if he was sitting in front of his PC at midnight on a Saturday.

Read More

How IT can alienate the very people they serve

By Patrick Gray

Takeaway: Patrick Gray talks about an instance when a company’s “geeks gone wild” alienated him from the product they offered.

I’ve been researching hosting providers (now universally dubbed “private clouds” by the trendy) for some experimental development work my company is doing. Ideally I’d like to use a provider who’s built their environment around a certain web standard, and with some research found the names of several recommended vendors in what is essentially a commodity market. I searched out the first provider, clicked their link in the search results, and was promptly greeted with a “Browser Not Supported” message encouraging me to download an unfamiliar application. Like the majority of the world’s web browsing public, I use Internet Explorer and have the latest version, IE9.

I should be in the ideal target market for this company. I’m looking for a host running a specific technical environment that they happen to support, I’ve taken the time to research this particular company and have come to their website directly and unbidden, and I have money to burn. Rather than welcoming me with open arms, they suggest I take 10-45 minutes out of my life to install unfamiliar software and change the very tool I use on a daily basis to interact with the internet. No thanks.

While there are still a few who cling to the notion of a “browser war,” the majority of people who actually have a life find a browser they like and move on to more pressing problems. While this is a blatant example of “geeks gone wild” at the expense of potential customers, most corporate IT departments are guilty of similar attempts to frustrate internal “customers” and alienate the very people they serve.

Take the lowly help desk ticket, for instance. Anyone who has worked in a medium or large organization has likely been told to “create a help desk ticket” before someone from IT will actually provide assistance. The rationale behind tickets is reasonable enough: IT wants to track where it is spending its time, and capture the problems it has encountered and fixed, to reduce time spent fixing the same problem. With the help desk ticket being the entrée into all things IT, one would think the experience would be exceptional and a hallmark of grand things to come. Instead, one ends up sitting on hold, or encountering an unfriendly online system that asks questions to which the user doesn’t know the answer-and far too many of them at that. In short, before that internal customer can even begin work on their problem, IT has created an adversarial relationship driven by an unfriendly interface.

Contrast this with something like the Disney theme parks. Before you enter Walt Disney’s Magic Kingdom, you’ve boarded a themed boat that slowly chugs toward a fantastic castle, with the themed music you’ve loved since childhood playing softly in the background. You’ve entered a magical and wonderful world, and this is before you’ve even pulled out your wallet to pay for admission. The initial IT experience at most companies would be the equivalent of being pelted with rocks, cursed at, and forced to walk through an unmarked maze just to find the entrance. The few who followed the process to its conclusion would arrive ornery and jaded.

It’s easy to joke about the help desk and regard it as a necessary evil, but like it or not, it’s the gateway to your IT experience and should be easy, frictionless, and perhaps even exceptionally pleasant. If you’re going to force every one of your customers through the help desk, employ some crazy ideas like actually staffing it appropriately so calls are answered quickly, and electronically submitted tickets are responded to promptly. You obviously can’t have your best and brightest technicians manning the phones 24/7, but you can have well-trained, competent people working the phones who log incidents, coupled with a dynamic and rapid follow-up that makes calling the help desk a pleasure rather than a dreaded inconvenience. Key to all these measures is realizing that your help desk is more than a bit of technology that helps your internal process, it is your face to your customers.

Just as the cloud vendor lost my business as soon as they suggested I embark on a long software installation and completely change my web browsing habits, IT’s touch points with the community it serves can alienate and anger internal customers. While they may not be able to take their business elsewhere, they are likely to remember how they were treated when it’s time for budget approvals and project proposals.

Read More

PMI's Agile Certified Practitioner: A cert is born

By Joseph Flahiff

Takeaway: The Project Management Institute’s new Agile Certified Practitioner certification might be right for you if your organization uses scrum, Lean, Kanban, and XP.

In February 2012 the Project Management Institute (PMI) began the Agile Certified Practitioner(PMI-ACP) program. Most project managers associate PMI with waterfall not agile, so you might be wondering not only if the world needs another certification but why PMI in particular is offering an agile cert. I’ll provide an overview of the genesis of the PMI-ACP.

Why PMI created this agile cert

In mid-2010 PMI conducted a survey of its members, and the results indicated that only 12% of the practitioners were using agile. In mid-2011 they conducted the same survey and found that over 27% were now using agile.

In response to this increase in agile usage, PMI assembled a group of industry thought leaders and authors including Alistair Cockburn to study how PMI should respond to this growing trend. These leaders were not just PMI’s best friends; some of the people were not even “friendly” with PMI, according to Frank Schettini, the Executive sponsor of the project. The Steering committee also had three PMI members, and those members were instrumental in other methodologies such as Kanban and DSDM.

In the initial meetings, only one committee member felt they would have a certification. After months and months of meetings, focus groups, and research, they found there wasn’t a common understanding across organizations of what agile means. Some organizations would say Scrum is agile, or XP is agile, or something else; while both Scrum and XP are agile, neither represents the complete definition of agile. The committee realized a certification was needed that clarified the core of what agile means and created a common language and understanding of principles across organizations. The PMI-ACP was developed.

Comparisons of the most common agile certs

Figure A is a general summary of the five major certifications in the agile industry as of this writing: Certified Scrum Master (CSM), Professional Scrum Master I (PSM I), Professional Scrum Master II (PSM II), Certified Scrum Practitioner (CSP), and PMI-ACP.

Figure A

A snapshot of the most common agile certs (Click the image to enlarge.)

There are other agile certs, such as DSDM, ICAgile, and all of the specific certifications for agile developers, but this is just a summary of the most common ones. (I am not including DSDM because it does not currently have the same global reach as the Scrum certifications, but it is an important certification.) A detailed analysis of the certifications is beyond the scope of this article. You can, however, read on the Whitewater Projects site how the PMI-ACP differs from the CSM and the CSP.

Which certification is right for you? Well, it depends. If you are just getting started and have no experience but want to learn agile and make yourself more marketable, I recommend the CSM or the PSM I or PSM II certifications. If you have experience in scrum and you see your career staying in organizations that focus on scrum, then I strongly recommend the CSP and PSM II certifications. If you have experience and work in organizations that use scrum, Lean, Kanban, and XP, then PMI-ACP is the way to go.

How will the market respond to the PMI-ACP?

It is hard to predict how the market will respond to the new PMI-ACP certification, but since PMI is the 800 pound gorilla of projects, it is very likely that HR departments of larger organizations will begin requiring the PMI-ACP certification.

There is evidence that the PMI-ACP is gaining ground and acceptance fast. This trend can already be seen on job sites like Indeed.com; there are already 20 or so jobs requiring PMI-ACP certification, and those positions are mostly for high-level positions such as program manager, Agile coach, and agile lead.

As of this writing, there are about 600 certified ACPs in the world, and most of them were from the Beta program and are coaches or consultants. So, if you are looking for that next strategic career move, the PMI-ACP could be just what you need. Like getting Microsoft at $14/share, you could get in on the ground level of something big.

Read More

Combatting the IT versus management mentality

By Patrick Gray

Takeaway: Patrick suggests some things that IT can do to combat the us versus them mentality.

My last article caused some interesting comments, many centering around the supposition that many IT functions, like the dysfunctional help desk I mentioned, were due to poor management. In essence, IT is not given the resources it requires and therefore is unable to deliver a product of the quality that many IT personnel wish they could provide.

There’s some obvious truth and comfort in this statement. Presumably a help desk, or any other internal function, would be exceptional with an unlimited budget, proper staffing levels, and all the best training and facilities. Comfort can be found in this assumption, since it takes the onus for excellence out of our hands. If an inadequate budget is the root of all of IT’s problems, and setting the budget is out of our hands, then we can easily tolerate any shortcomings since it’s “their” fault rather than our own.

I have yet to meet anyone in a modern corporation who laments an overabundance of time, money, and staff. In short, every corporate function, especially those that are internally focused, is competing for scarce resources and will likely never receive what it perceives as an appropriate budget. This problem is compounded by the fact that IT costs are far more transparent than they used to be. In the early decades of corporate IT, costs were perceived at the executive level as a “necessary evil,” with the “right” budget being a bit mercurial. Now the CFO merely needs to mention that he or she is considering outsourcing some IT-related function, and a line of vendors with detailed cost proposals appears outside the door. So how can IT combat this “us versus them” mentality? I’d suggest the following:

Assume the best

Many people assume bad intent when it comes to their direct management, and even worse when regarding upper management. A budget cut is a personal slight, and layoffs clearly the fault of “clueless jerks” sitting in the corner office. This attitude again makes one the victim; if unseen nefarious forces exist to derail your efforts at every turn, why bother doing anything more than showing up and clocking time until retirement. Simply shifting your view may change how you perceive management and its actions. Rather than immediately assuming the worst, assume your direct and upper management are fallible human beings, tasked with wisely managing and allocating scarce resources.

While this may seem like a perceptual game and waste of time, it can provide concrete leverage, whether you’re reporting to the CEO or line management. When a decision is made by a bad actor hell-bent on derailing your career, you have little choice but to grumble and accept the decision. If that same decision is made by someone struggling to achieve a difficult balance in allocating scarce resources, you can make a compelling case that there are different ways to achieve that objective that might provide more direct benefit than another decision. In short, assuming the best empowers you.

Look for business benefit in every decision

The other weapon for IT against budget cuts and supposedly misguided management decisions is couching technical and process-related alternatives in terms of business benefit. As I mentioned in my previous column, a company I was considering doing business with set up their homepage so it would not load on Internet Explorer. While there might be technical reasons for this decision, many pointed out the obvious flaw from a business-benefit perspective, mainly turning away potential customers before we could even read about the company’s offering. Similarly, if your help desk is understaffed, requesting additional resources clearly spells out the cost side of the equation (hiring and salary expense for new staff) without clearly delineating the benefit. The same thing routinely happens when IT engages in heartrending debates about technical alternatives without considering the inherent business benefit.

When you combine a consideration for business benefit with assuming the best in corporate management, IT becomes a compelling investment of scarce resources. Similarly, management becomes an entity that can be convinced, persuaded, and collaborated with, sometimes with your preferred result, and sometimes not, but in both cases a very human and rational entity, rather than a nefarious and insurmountable entity that beats IT into victimhood.

Read More

Facebook goes from 54 patents to a whole war chest

By Gina Smith

Takeaway: As Facebook builds its war chest of patents from IBM and Microsoft, the three have been mum about exactly what patents Facebook has been buying in the last month. Here’s exactly what it got from IBM – and, surprise, some patents from Verizon, too!

What’s in those Facebook patents it bought from IBM for an undisclosed amount in late March? Facebook is vague. But a trip through the U.S. Patent and Trademark Office Assignment Database reveals what’s in the 750 patents Facebook bought recently from IBM – the ones it bought from Microsoft aren’t up yet – and the database also reveals what Facebook received in super low-profile deal from Verizon.

So check out Facebook’s growing war chest. What you will notice is that there sure is a lot of hardware in these patents. This is a huge and wide-ranging portfolio – even without being able to see yet what Microsoft is selling Facebook – that will help Facebook counter suits. But notice a theme in the IBM patents. Hardware. A lot of it.

Could a mobile Facebook smartphone, tablet, TV or net device be far away? You be the judge. At this writing, Facebook reps were unavailable for comment. I say it’s only a matter of time.

Take a look at what Facebook just recorded as having purchased from Verizon. A lot of location-based services and other tech.

Verizon to Facebook

Now look at just one sampling – more below the break – of exactly what it scored from IBM. Facebook is filing these on the USPTO assignee database. Here’s one bundle:

IBM to Facebook Patents 2012

Surely, the huge patenting up of Facebook – it had 54 before Yahoo sued it last month and now is buying patents and licensing patent like crazy – is a necessary move for Facebook.

It creates a patent collection Facebook can use defensively or offensively, as it chooses. Facebook needs them to fight Yahoo and others. Yahoo complained last Friday in this filing that the patents Facebook is buying are just last minute purchases when, in fact, its own allegedly infringed (by Facebook) patents are Yahoo-native.

This is true but it isn’t illegal. My colleague, renowned patent lawyer Tom Ewing, analyzed exactly this phenomenon of just-in-time patenting almost a week ago, explaining the nearly ubiquitous practice of just-in-time patenting and why it matters so deeply to tech consumers and tech pros. Basically, it allows companies to mount giant claims against one another based on patents they didn’t themselves invent or utilize – costing millions to billions in litigation tech-wide, which adds cost to products you use and slows innovation, at best.

“Most of the Yahoo! patents in that offensive suit were Yahoo homegrown. But Facebook’s countersuit is a collection of newly and rapidly snagged patents — Facebook hastily assembled 10 of them after Yahoo sued it (as court documents show) These are protection patents — aka just-in-time for court patents. Facebook bought eight of them for last minute protection and this is perfectly legal. Its fairness isn’t as clear. Certainly, a young or poor individual inventor can’t purchase litigating protective patents for enormous sums of money.” (http://anewdomain.net/2012/04/28/facebook-microsoft-aol-ibm-patents-why-these-billion-dollar-deals-matter/)

And just-in-time patenting isn’t new. Patent watchers will remember the 2010 TiVO vs. Verizon case, where Verizon purchased just-in-time patents to defend itself.

“Now that Facebook has nearly 1,500 patents, its competitors will be a lot less likely to seek to use their patents to terminate the company’s business concerns. With that many patents in its arsenal,” says Ewing. Facebook will be formidable from a patent standpoint and hard for competitors to attack. And yes, as Tom noted last week, eight of the ten Facebook patents Facebook is using to countersue Yahoo were purchased “just-in-time” and came from other companies right around the time Yahoo sued Facebook.

Now check out the reams of patents – 750 in all – Facebook received from IBM and notice the hardware (a lot of semiconductor and telecom) tech predominates.

Yet more IBM to FB

More IBM incoming to Facebook patents. Think circuitry, memory routines, mobile, communications tech:

IBM to Facebook Patents 2012

More hardware patents from IBM to Facebook:

IBM to FB - 007

Another new batch of IBM to Facebook patents:

IBM to Facebook - 008 — bundle eight patents anewdomain.net gina smith

You’ll find some interesting tech in this bundle:
IBM to Facebook - 008 — bundle eight patents anewdomain.net gina smith

More IBM patents now in Facebook’s collection:

IBM to FB - 009

Microsoft, too, would not comment to this reporter on what patent numbers are on the patents it sold to Facebook – but they’ll be public record awfully soon. You can check as Facebook posts them with the USPTO. Just click here and enter Facebook in the field labeled assignee.

That’ll show you the whole patent portfolio Facebook has purchased (or received as an “assignee”).

At of this writing, the number of patents in the chest is at 854. Facebook will soon be recording the mysterious Microsoft patents. So keep your eye on the assignee database to find out what Microsoft isn’t ready to reveal the minute it is forced into public record.

Read More

Four more things your IT department should consider not doing

By Scott Lowe

Takeaway: Most organizations might not be ready to shift these activities, but here are four more items you might want to consider doing.

A couple of weeks ago, I wrote an article entitled “Six things your IT department should stop doing today” and received quite a lot of feedback.  The feedback ranged from “Right on!” to “If we do all of this, we won’t have jobs!”  While I don’t agree with job preservation as a singular goal for IT staff, it’s an understandable sentiment.  That said, I continue to believe that IT organizations should do everything in their power to shed the mundane items outlined in the previous article in favor of activities that have a more substantial business outcome.

In addition, there are a few other items that IT departments should consider in their efforts to eradicate the mundane from the portfolios.  This list, in my opinion, isn’t quite the slam dunk that I consider the previous list to be.  The items listed require careful consideration before making a major move and, for some, the business or the culture may simply not be ready and may need further preparation before the activity can be shifted.

With that said, here are a few more items that CIOs should consider removing from the IT portfolio.

Writing reports for users… to a point

I’ve seen organizations that rely on IT for each and every report to be run.  Let me be clear: The end users simply did not run reports.  The IT Help Desk was contacted and a request submitted even for an existing report to be executed.  This is a waste of time for both the end user, who now has to wait for someone to run the report, and for IT, who now has to simply execute the report.

The situation may be different for an end user that is requesting the creation of a new report.  While there are a number of self-service report creation tools available on the market, some reports are particularly challenging and require additional technical analysis in order to complete.  As such, the creation of the new report may wind up as a collaborative venture between IT and the end user in question.

Note that I indicated that this should be a joint venture; this is still not a case where IT will go it alone.  The expectation should be that the end user knows what he wants and can articulate that need in some reasonable way.  It may take a few iterations to drill down to the perfect solution, but ultimately, the end user has to know what he’s asking for.

Many of you will respond to this item with, “Yeah… that’ll never happen.”  And, you’re probably right for one of two reasons: 1) Your organizational culture is one in which the IT department is simply a bunch of order takers; 2) Your own thinking is getting in the way.  The worst that you can do is to try to get users to a point where they are asserting some level of ownership over the informational activities that they need to do their jobs.  If your culture simply rejects the attempt, so be it, but don’t give up before giving it a shot.

Deploying physical servers… to a point

These days, with a modern infrastructure, the underlying components necessary to deploy a new application can be provisioned in mere hours–or even minutes–as opposed to the days, weeks or even months that it would have taken in an all physical world.

There remain IT organizations out there that remain steadfastly opposed to virtualization, labeling it as a “flash in the pan” that will go away.  It’s not going to go away and the advantages are simply too great to ignore, even for smaller organizations.

Deploying a physical server is a lot of effort and requires racking, cabling, cooling and a lot of human intervention.  Although virtual environments still rely on these efforts, once they’re deployed, managing them is much easier and new service deployment is a snap.

With the benefits that come from Microsoft’s virtualization rights associated with Windows Server Enterprise and Data Center, the licensing cost break-even to go virtual is around seven virtual machines.

Web content changes

This one used to frustrate me to no end.  Simple web site content changes required a high level IT staff person to execute.  Although web content lies squarely in marketing’s lab, it requires that the marketing people be trained on the use of the content management system software and that they have the willingness to learn how to use the content management system software.

In general, IT staffers will maintain the underlying web infrastructure and may work at a high level on content when there is a need for sophistication beyond the normal.  However, if there is an IT staff person that is constantly doing small content updates, those activities should be housed in the marketing area, freeing up that IT staff person to add features and functionality instead.

This one isn’t the slam dunk that I believe some other suggestions to be, however.  It’s more political and, in many organizations, the IT department is in charge of the web site.  In these cases, it makes sense for IT staff to be doing web work.

Communications services financial management

I learned this one the hard way.  Working on monthly phone bills carries with it absolutely zero value add to the organization beyond being able to charge every department for their 37 cent phone calls. There are a lot of ways that this activity can be made someone else’s problem:

Outsource the management of the communications billing.  There are many, many companies out there that specialize in telecommunications invoice and service handling that would be more than happy to take this task of your hands.

Move to a flat rate service.  For local and long distance wired service, this is what I did in a previous position.  I moved to services that included enough minutes that we never had an overage.  In one position, this meant a move to SIP trunks.  In both cases, the organization saved thousands of dollars per year while, at the same time, the phone bill became easy to manage.

Read More