We execute most organizational initiatives in a certain way. Why do we do tech projects differently — and then complain? Well, things technical are not easily understood by most business folks and therefore tech projects are considered best left to the experts. This means these projects may not produce outcomes like typical business projects do. We need to reverse the situation. We need to put tech projects in the business context. Here are three suggestions.
1. Start with the business context
Where should we begin? While it is a good idea (even an important one) to be aware of new technologies and what they can do, the best place to begin is the business context. Technology that did wonders for one organization may not deliver the same results for another organization. We should therefore begin by knowing our organization’s overall strategic agenda. Clearly, this is not about an agenda defined by departments. An organization’s departments may be well-intentioned, but each department's agenda could be siloed.
2. Execute in the business context
Having understood the organization’s agenda, we move on to the real action: project execution. However, we need to execute projects in a crucially different way. We start with a new activity. And it’s called strategy translation. That is, we: (1) discover stuff that has the potential to deliver on the organization's agenda, and (2) design the stuff so it really packs the potential to generate targeted strategic outcomes. Here, “stuff” is not just technology, but is almost always a blend of technology and business change. Having done discovery and design in the business context, we “return” to the project phase that traditionally received the most attention: technical implementation. We’re pretty good at this. So we’ll use our traditional strengths.
3. Assess in the business context
If we successfully completed the previous two suggestions, business context has been front and center in the project, literally! That’s remarkable. And yet, we’re not done. How do we check and conclude whether or not the project was a success? Well, traditionally, project success meant “delivering quality technology on time and within budget.” While this is still important, the determining question though is whether the project generates outcomes targeted based on the organization’s agenda. So we should be prepared with techniques to make assessment in an objective, measurable way.
So . . .
Overall the suggestions may sound obvious. In fact, some of us may think we already follow these suggestions. If so, consider, most importantly, the second suggestion. Do we really keep the business context while executing a project? It is through discovery-and-design that actual strategic alignment can happen. Do we use a strategy-driven method to discover and design? If not, it’s time to focus on this.
When we’ve mastered the method and the skills to execute technology projects in the business context, we’ve mastered how to execute tech projects like business projects.
This article is published as part of the IDG Contributor Network. Want to Join?