How To Speed Up Key IT Projects

Lessons learned from 54 intense, team-oriented hours at Startup Weekend in Charlotte, N.C.
Sometimes, you learn the most at events only incidentally connected to your day job. So it was at the Charlotte, N.C., Startup Weekend I attended a few days ago. It was an idea-to-execution competition among teams that form at the event, billed by the organizers as "experiential learning." They delivered: I learned how self-imposed constraints can speed up technology projects.

I'm not an entrepreneur, but spending 54 intense hours, mostly with people I didn't know, to go from pitch to plan to implementation of a technology business taught me valuable lessons about tech leadership. In an era when IT is perceived as "Too Darn Slow," this event confirmed for me that we can speed things up to achieve competitive advantages.

Rapid Execution Begins With A Good Pitch

"The pitch," also known as the elevator pitch, is when the person with the idea explains it quickly, in the time it takes to travel from floor to floor in an elevator. Point is, you've got to get people excited about "the plan" before you get the resources and/or round up the people to embark on that plan. Do you do this with your IT projects or initiatives? If you're hoping to execute quickly, you'd better. If staff and executives don't buy into the idea, there's no way you'll build the sense of urgency needed to execute it quickly.

During the weekend, we got 90 seconds to explain each of our ideas, which, from what I understand, is generous for these types of events. I observed that the best pitches answered these questions: Who am I? Why should you listen to me? What's my idea? What problem does it solve? Why should people care about it?

It helps, of course, to be prepared. The best pitchers practice, which builds confidence and conditions them to stay within the time window. Nothing deflates a pitch more than a lack of focus.

Oftentimes with staff, executives, and other peers, you won't have much time to explain. If you run out of time, it reduces your impact and hurts your credibility. "What the heck was that dope getting at?" your audience will wonder as they rush off to their next meeting. Drawn out detail is for plans. Brevity and clarity are for pitches.

Do you think your next pitch of an IT project or process change is important? You may not have much time with the influencers, so practice it within a time constraint.

Buy Before Building

At Startup Weekend, my team prototyped a project, called Wi-Fi Crowd, that involved SMS messaging. Years ago, we would have had to order specialized hardware and then learn how to code against that platform. Just taking delivery of the hardware would have been difficult in a 54-hour window. Then we would have had to start testing at a small scale, and pray that our solution would scale up.

Global CIO
Global CIOs: A Site Just For You
Visit InformationWeek's Global CIO -- our online community and information resource for CIOs operating in the global economy.

Instead, our tech team tested Twilio (a cloud-based provider of telecom services, to handle all SMS traffic) for free, found that it worked, and then bought an account for a more feature-rich service. By the time the event was over, we had a working product to demo for the panel of judges. Pretty sweet.

In my experience, too many technologists try to build everything themselves. If your IT organization wants to be nimble, it must understand that the world has changed. If you're looking to do basic operations like sending a text message or email or collecting money, someone is probably selling it as software as a service. Ditch IT's long-standing "not invented here" attitude.

From a leadership perspective, make sure developers seek solutions before building. Respond to developers who think "Why spend money when we can do it for free?" by telling them that their time sure as heck isn't free. You'll save critical staff time and execute far more quickly.

Budget Time For Debate, Seek Solutions

As startups do, the business plan team spent a lot of time in the weeds, arguing about lots of different options. We went off the rails twice and spent five to eight of our precious 54 hours in heated debate. By the end of the event, everyone on the team realized that we needed to go off the rails a bit in order to pursue the ideas we settled on. During idea formation, you really don't know which ideas will work. You have to chase them and wrestle them to the ground. We did man-on-the-street interviews, reached out to professional networks, and even created a Facebook group to test some of our ideas.

Of course, we would have failed to execute within the given timeframe if we had stayed in endless debate mode. Two things helped us. First, we had a compelling pitch. When we started to veer away from the initial idea, the pitch brought us back to common ground. Second, we budgeted time to debate certain points, with a key ground rule: It's easy to find fault with something, but let's focus on how to make it work. We agreed that if we didn't enhance the idea within a given timeframe, we'd move on.

All in all, it was a successful weekend for the team: We took honorable mention. But more important, we left with lessons we would apply to speed up our IT and other business initiatives.

Jonathan Feldman is a contributing editor for InformationWeek and director of IT services for a rapidly growing city in North Carolina. Write to him at [email protected] or at @_jfeldman.