Putting on my best project management hat, I tried to get her to think about what she really wanted to be able to do--besides link several computers together. What was the business need that wasn't being served by her current arrangement? "Well, I'd like to be able to work on the books anywhere in the office while my receptionist types letters...you know, in the waiting room, in an empty exam room. And I'd like to be able to take financial files home to work on."
"Does your receptionist ever work on the books?" "No." "Are the books tied to the scheduling system?" "No." "Do you ever type letters yourself?" "Not usually." "Do you need to print anything out at the office?" "No." "How about accessing the Internet?" "No." "Then maybe, for now at least, you could simply start with a laptop that you could use for your bookkeeping and worry about networking later--if in fact you ever need to take that step."
As simplistic as this example is, it illustrates a mistake that enterprises can easily make with IT projects: not being clear enough about business objectives before jumping head first into implementation.
I'm sure my dentist could find someone willing to install a network for her--at a price-- and I suspect that some third party has already been trying to put the network bee in her bonnet, but it isn't really what she needs at the moment. Even if the networking project came in on time, under budget, and according to specifications, she still wouldn't be happy in the end, because the "solution" wouldn't have addressed her main problem, namely being able to work on her books anywhere in the office and at home.
Come on, you may be saying. This wouldn't happen in a larger company, where there are business analysts paying careful attention to corporate needs and recommending IT strategies. They don't even think about starting an IT project until they're clear about the business need.
Yet in a report published a few years ago, the Standish Group noted that large companies by and large had a rather disappointing track record for delivering IT projects that actually met the business needs they were originally intended to address:
...even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally proposed features and functions.
(http://www.standishgroup.com/sample_research/chaos_1994_1.php)
Smaller companies seem to be more successful in their efforts, but only marginally, and they have problems, too.
There are many reasons that IT projects frequently end up not doing what they were intended to do, among them lack of management support, unclear requirements, inadequate planning, unrealistic expectations, and changes in business needs along the way. Yet if you look closely, you'll see that they quite probably all stem from a far too common source: less than crystal-clear objectives.
Good objectives, in any endeavor, are clear, unambiguous statements of results or outcomes. In education, they spell out exactly what a learner will know or be able to do as the result of a particular learning experience. In testing, they specify exactly what an examinee needs to be able to do to be judged competent in a particular area of expertise. In business, they identify exactly what business problems will be resolved and what business results will be achieved--or at least they should.
Unfortunately, people often think they're setting clear objectives when they're not. How often have you seen objectives like "improve our customer service" or "make our Web site faster"? Those objectives may sound good, but they're far too vague to really mean much. What is the specific measure of improvement in customer service or Web speed that the business is aiming for? A 60% increase in the number of problems resolved on a customer's first call? A 35% reduction in the time it takes to load a company's home page over a 28K connection? Only if you have unambiguous, measurable outcomes like those will you know what you're really trying to achieve.
A classic example a few years ago was the California Department of Motor Vehicles. The Standish Group politely cited "unclear objectives" as one of the key reasons the DMV failed in a $45 million, six-year project aimed at revamping the state's driver's license and registration application processes.
But let's call a spade a spade. According to the DMV itself, "the specific objective...was to use modern technology to support the DMV mission and sustain its growth by strategically positioning the DMV data processing environment to rapidly respond to change." Come again? With an objective that ambiguous, how would you even know where to begin, let alone where you were likely to end up $45 million and six years later--or whether revamping application processes was even supposed to be part of the project?
(http://www.standishgroup.com/sample_research/chaos_1994_3.php)
Some people shudder when they think about having to define clear objectives--business or otherwise--because it's difficult for them to think about unambiguous outcomes. Others frankly may not want to be very specific about outcomes if they can possibly help it, because they think it's politically risky to commit too early to what they want. What if they've miscalculated? We all know who those people are, and they can be the kiss of death for a project. But insisting on unambiguous, measurable objectives and keeping teams focused on them is one of the most powerful tools around for improving the chances of IT project success.
Here are some of the areas in which well-crafted objectives can have a particularly significant impact.
- Getting meaningful stakeholder buy-in, including executive support
Most classic approaches to project management stress the importance of getting "stakeholder" buy-in, usually meaning simply sign-off. However, just getting sign-off is not really sufficient. Many a stakeholder and executive has signed off on project goals that they don't really grasp or that are so ambiguous as to be meaningless, only to retract support later or argue that the project didn't deliver.
Unambiguous business objectives spell out explicitly what a project will and will not do and what the project is going to "buy" for various constituencies. When there is little or no ambiguity, a senior executive is much more likely to endorse a project--and continue to endorse it as it begins delivering the predefined, measurable results it was intended to deliver.
- Dispelling the notion that a project is being driven purely by technology
One of the worst things that can happen in an organization is when executives begin to believe that IT projects are being driven purely by technology rather than business issues and performance. This misconception can result in management refusing to sign off on projects to begin with, withdrawing support along the way, or ceasing to deal with technology project managers altogether, instead assigning someone to be a "liaison" between the business side and the technology side, essentially leaving the IT project in no-man's-land. The further executives get away from direct involvement in projects, the greater the risk that the project will lose management support--and fail.
Unambiguous, measurable business objectives make it clear from the outset that the project is being driven by business outcomes. Executives and management clearly see the project--and its progress--in business terms and thus remain committed and close to the action.
- Managing change/juggling priorities/managing trade-offs
Change is the norm rather than the exception in IT projects. The trick is how to manage it. Do you have principled means for deciding which changes are legitimate and which are not? which priorities need to be juggled? which trade-offs are most important for the project?
When the objectives for the project are unambiguous, so are those decisions.
- Controlling scope creep
Scope creep can begin innocently enough. An executive might say, "As long as we're doing x, let's also do y." Or a member of the IT team might say, "While we're doing this, let's also fix that." It can be hard to fend off suggestions like those if there's no clear definition of what the project is supposed to encompass in the first place.
If, on the other hand, there is a very clear, unambiguous definition of the business objectives of the project, it is much easier to assess how any particular new "feature" will enhance it--or push it off track.
A case in point: A specialty retailer was concerned a few years ago that its Web site might not have the capacity or scalability to deal with what it anticipated to be a heavy Christmas shopping season. It also felt it needed to change the way its Web site orders were fulfilled. Since Web site orders were processed from the company's catalog operation via a single nightly update (whereas catalog orders were processed dynamically throughout the day), it was possible that items would not be in stock by the time the Web site orders were ported to the catalog order processing system. The company determined that its primary business objective was to solve these specific problems in time for the holiday season.
The retailer also had a number of other business interests and concerns. It wanted to enhance its marketing and sales support activities as well as its ability to use the Web site to cross-sell with its catalogs and stores. A consultant noted that it might want to integrate its Web site, catalog, and in-store processes even more tightly, allowing merchandise ordered via the Web to be returned to a physical store.
All of the latter "enhancements" were tempting extensions of the original project, but the company's primary objectives were clear. Its most important priority was to deal with the capacity/scalability and order processing issues by Christmas. The other enhancements would extend the scope of the project and pose the risk that it might not be finished on time.
The company stayed focused on its primary business objectives, completed the project, and--happy to say--had banner Christmas season sales, with even more customers visiting its site than its original capacity and scalability estimates had anticipated. It could easily have had a disastrous season if it hadn't been clear about its objectives going into the project--or hadn't stuck to them.
- Meeting expectations and ensuring "stakeholder"--especially customer-- satisfaction
Almost everyone has different expectations for a project: senior management, end-users, team members, and customers. If the objectives of the project aren't clear, it's difficult if not impossible to be sure you're meeting the right ones.
My ISP recently set out to "improve its customer service" by making it "easier" to find a local dial-in number. It apparently wasn't much more explicit than that when it formulated its objectives, since the "solution" it implemented--having the customer type in a specific, active local number and then returning a dial-in number "closest" to that exchange--in fact made it easier for customers to find a local number without having to check a list, but it also made it next to impossible to find alternative dial-in numbers in the area--or numbers in localities to which one might be traveling--without entering real, live, active phone numbers from the target community on a trial-and-error basis.
So whose expectations, exactly, were met in this case? Perhaps those of whichever ISP staff members thought up the idea and possibly those of the development team that implemented the solution, but certainly not those of the customer. The ISP will no doubt have to re-do the project, at additional expense. In the meantime, it has created considerable customer ill-will. The problem could have been avoided if someone had insisted on more unambiguous objectives.
Since business objectives underpin so many of the factors that contribute to IT project success or failure, getting clear on them--and staying focused on them--is one of the single most important ways to impact success and failure rates. It's also much, much easier to demonstrate that, in fact, you've been successful when you're finished (in fact, to know that you are finished) when you've defined from the get-go just exactly what the real impact of a project is supposed to be.
Articulating clear objectives is not always easy. Some people find it easier than others to envision unambiguous outcomes and formulate them in ways that are intelligible to various project "stakeholders." If you have such people in your enterprise, capitalize on them. If not, try to cultivate some. They can be one of your greatest resources for improving project success rates.
John Knapp is currently an independent analyst and author. Formerly, he was a college professor, a Senior Industry Analyst with Andrews Consulting Group, an association executive, and a Manager of Program Management for Sylvan Prometric, not necessarily in that order. He can be reached by email at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online