Three Tips at the Tip of the Iceberg: How to ensure the success of your IT projects
IT no longer needs to play the role of an overhead scapegoat. IT is a key bolt within the organization, and it’s time we start acting like it. If you are reading this publication, you may be a step ahead, because you’ve already made the connection between IT projects and the need to integrate Pragmatic Institute’s approach to technology as a business.
In this article, we’ll touch just the tip of the iceberg with three key points to help you ensure the success of your IT projects.
Tip #1: Become a customer/market expert
Tip #2: Become proactive by aligning your IT projects with corporate strategy
Tip #3: Position the value of your IT projects to the organization
Although this is just the tip of the iceberg, it is no small feat. Prepare yourself to take small steps towards accomplishment. This is a large undertaking and requires planning—just like any other successful project or product. Remember the old saying, “A journey of a thousand miles begins with a single step.”
Tip #1: Become a customer/market expert
For years, IT has focused on the technology rather than the customer. Who is our customer? Who is determining which projects your IT team manages? And who in your IT area is playing the role of product manager?
Sadly, many IT organizations approach projects as though they are custom-programmed for a single user. But even internal projects should be treated as products—products that are used by more than one person, one department, or even one business unit.
And who is managing these projects as repeatable products? Likely no one—because this project/product disconnect is a view that is not yet common in the IT world. This means business problems are likely not being clearly identified—which, in turn, means you are often working on the wrong projects and/or not positioning your projects based on the value they provide customers, users, and the bottom line.
It’s time to realize that IT has customers, too. We need to stop thinking about one person in one department, and instead focus on a market full of customers in our business units.
Your role as the customer/market expert
How are you tracking customer input? This is a vital role. If you have no dedicated product manager for your deliverables, all IT staff should have the means to identify, log, and track information gathered in the field. For example, how do you know that all 32 departments are complaining about the same business (not technical) problem?
How will you identify pervasive problems? IT staff looks for technical problems to solve, so asking them to identify business problems will take some training and direction to expand their expertise. To the best of your ability, you should learn everything there is to know about product management.
Before this task ever becomes a project, there are many vital functions normally accomplished by a product manager. A typical, well-run vendor product team has these six roles:
Product manager, who finds and quantifies market problems
Product designer, who defines solutions to the problems
Development manager, who manages the development team
Quality assurance manager, who assures quality from the customer perspective
Project manager, who manages complex products beyond just the programming
Product marketing, who launches the final product to the market
How do these roles correspond to the typical roles found in internal IT?
Let’s take the IT Project Analyst role, for example. It is an interesting one because the roles of product management, product marketing, and project management are combined, but this combined focus is usually not well defined.
An IT Project Analyst typically struggles to identify exactly where his or her responsibilities begin and end. Moreover, even if that person has the product management and marketing responsibilities, he or she usually has little or no background or knowledge in that area. You can enhance this person’s expertise, morale, and success by providing training in product management, including defining roles and responsibilities.
The IT Project Analyst is typically handed the project scope, including all the information the requestor believes is pertinent: project value, financial impact, business problems solved, and so forth. You might even have a standard project request form that requires this information. This project request is then evaluated and prioritized by IT to determine when it can go on the schedule and whether or not resources are available.
We hope you are questioning this process, because you would be right. What’s missing here? We have a single requestor presenting a project idea—and IT runs with it? Of course they do, because they don’t have the product management role in place to do the additional research, observe users and business problems, and identify the impact/benefit to all other prospective users.
Most importantly, the requestor is usually too close to the project to identify the true business problem. Without identifying the true business problem, you will likely work on the wrong project; and, when it is complete, the requestor will tell you it’s not what the user requested.
In a combined responsibilities role such as IT Project Analyst, another issue is the lack of checks and balances. When the product management/marketing role is separate from the project management role, you gain value from the dialog that happens in reviewing and verifying requirements. And, you free up the project manager to lead the project. If this combined role is what you have to work with, however, make sure you identify ownership of customer/market expertise and include those tasks in your project initiation and planning stages.
Tip #2: Align your IT projects with corporate strategy
A product manager not only focuses on the customer and market, but also on the corporate strategy. For some of you in the IT environment, this may sound strange. But it is imperative to know the corporate strategy and mission, as well as the roadmap, inside and out.
This knowledge enables and empowers you to position your services and projects correctly. Use vocabulary that clicks with the strategy and, therefore, with management and executives.
A key here is finding a “mentor” in the organization who will keep you in the loop about the corporate strategy. If you are a manager or director in IT, volunteer to participate on strategy teams and in planning activities. If you are lucky enough to have a project analyst who truly understands the role of product management, send that person to the strategic planning meetings. The mentor may help you be in the right place at the right time.
You may feel unwelcome at first; but sit back, absorb, and learn the ropes of contributing to the strategy. After all, the organization’s lifeline is (or should be) its strategy. If your projects aren’t aligned with that lifeline, your projects’ lives aren’t really that valuable; are they?
Tip #3: Position the value of your IT projects to the organization
If you’re not integrating the Pragmatic Institute Framework (especially positioning, customer visits, and strategic alignment) into your IT projects, you are not measuring and demonstrating your value to the organization. Moreover, you are probably in need of a gap analysis to identify where you should focus your efforts to improve your visibility.
Walk through each box of the Framework. Who owns this (if anyone)? How well are we performing each box? This exercise will identify gaps between your current state and your desired state.
At first glance, you may think that some boxes don’t apply to you. When you think about your last project that failed, however, you may realize how these “inapplicable” boxes might have helped that project succeed.
All of the boxes do apply; but, depending on the gaps you find, you may need to prioritize your attention. You won’t be able to fix everything overnight. When prioritizing, remember that you probably have some catching up to do regarding proving the value of your IT team, so you may want to base your priorities on this objective.
Promote your projects
Who says IT doesn’t need PowerPoint? Get out there and promote your projects and your value to the organization.
All of your project managers and IT leaders need to incorporate “selling the project” and its value to the corporation into every single initiative. As a simple, initial step, this promotional aspect should be included in every project’s communication plan. Your IT team may also enjoy the visibility along the way.
Be sure you have the customer expertise and market data to back you up. As Pragmatic Institute advises, it is about n=many, not n=1. In other words, don’t target your efforts at value for a market of a single user; instead, focus on the deliverables that benefit the majority of users. This may mean your team will need to develop tough skin. Learn to say “no” to executives and managers (with supporting evidence, of course).
IT is often forgotten in corporate-level planning. As you increase your visibility and use positioning to demonstrate value, watch as you increasingly become included and involved much earlier in corporate strategy and planning.
A case study from Anita Wood
By way of example, consider an IT project where I applied this process. The high-level business problem had been identified and brought straight to the director, long before I became involved as IT Project Analyst. Since this was an enterprise-level initiative with a lot of visibility, I knew we absolutely needed product management and marketing activities. Fortunately, I had a product management background that enabled me to identify a gap in the process.
I leveraged analyst and industry expert research to support the value of the project, and I relayed that information throughout the project to gain buy-in (via PowerPoint!). The key, I believe, is that instead of accepting what was handed to me as “the requirements,” I conducted customer and department visits to personally observe their problems.
I identified all problems (not just a subset) and was able to articulate complete, prioritized requirements. Not only did this process create a better product, it helped create a better rollout, too.
Because I observed and listened to actual users, I was able to identify the true business problems. For example, one department was handwriting hundreds of labels per month because they didn’t have the correct device to print them. That type of business problem would never show up if you simply examined the device inventory. This success came about by watching how users work and identifying manual steps that weren’t being solved by their existing devices.
“Many important aspects of work are invisible, not because they are hidden, but because it doesn’t occur to anyone to pay attention to them.”
– Karen Holtzblatt and Hugh Beyer, Contextual Design
Now, with the true business problems identified, we were able to find innovative solutions for the various scenarios. “Cookie cutter” was no longer the optimal way to make this project succeed. The best part of that process was seeing that users were grateful to be involved in the process and simply have their voices heard. By the time we presented recommendations—some of which were difficult to swallow for departments—the pushback was minimal, because the users understood the value and had been heard.
All along the project timeline, I scheduled ways to promote the value of this product-oriented approach to IT projects. I promoted all of our successes, even the smallest wins. I tracked metrics such as number of devices removed; number of oversized devices reallocated; examples of process automation to increase user efficiency; and expected savings. I used those metrics to communicate a monthly report of wins to the executive level. Publicizing wins along the way also increased adoption across the organization (i.e., public humiliation of the resistors).
Reporting and tracking was also vital to this project’s success. By having good metrics to quantify the business problems upfront, we could demonstrate the comparison and improvement after implementation. We gauged success and increased customer knowledge, awareness, and empowerment. Clearly, sharing case studies, no matter how small, kills several birds with one stone: communication, visibility, and education.
Be a product manager vs. a project manager
The conclusion here is that we should treat IT projects as products. We should solve problems for a group of customers—a market full of customers—rather than wasting limited resources on a market of one. We act more like product managers and less like project managers.
Don’t lose hope—although this may seem daunting, it is achievable and well worth the effort. IT absolutely has the capability to become a customer/market expert, align projects with the corporate strategy, and position its value to the organization.
IT is already a vital cog in the wheel, so now it’s simply a matter of ensuring you are working on the right things and that you have an audience. The way to do that is to educate yourself about product management and marketing roles.
Be creative, and take small steps. Start with the resources and tools you currently have. Identify your gaps and work in phases. And most importantly, choose the optimal timing to begin promoting yourself. Track your progress for, say, six months, and make sure you will be a shining star when you step on stage.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.