The turn to October means a lot around the DC area. It means colder weather. It means the local professional football team is almost out of the division race…and I can say that, I’m a fan. It is the season for pumpkin lattes, beer and wine festivals, fall foliage…oh, and it’s the start of the government’s new fiscal year. The start of the new FY means new money, new ideas, and new projects. So, let me take this moment to converse with all of you IT Project Managers out there. DON’T BUILD YOUR SYSTEM IN A VACUUM! The organization I support did it for 20 years, and now it’s taking a lot of smart people and a lot of money to figure out how to get all of the systems and “pet projects” to communicate. And while I’m happy to assist wherever I’m needed, full transparency, I’d rather be focused on helping them push the boundaries of their technological/capability needs, then focusing on what’s already been accomplished.
Therefore, I’ll spend the rest of this post will focus on 3 dos for your new IT project, and 3 don’ts so you can avoid having to hire someone like me in 20 years. If you focus on the do’s, stay away from the don’t, your current and future tech teams will thank you. And if, by extension, you want to have them buy me a beer at an upcoming festival, I won’t complain too much…
3 Dos for your next IT Project
Do #1: Do focus on Open Standards
The first step in not building applications in a vacuum is to build your systems in such a way that others can interact with them. Typically, this revolves around building RESTful Web Services that produce JSON/XML; although, others may be required based on your requirements.
Do #2: Do break your requirements down into their smallest components
The prevalent idea in the tech industry today is “fail small, fail quick.” That means, get a seed of an idea out there, and let the community water it. Let the community grow it. See how people interact with it. And if they don’t, then that’s fine too, because you didn’t spend a lot of money producing it.
This can also apply to your development practices. How many systems require a user to first authenticate and authorize themselves (read: log in)? Now, imagine if you could build that once and then reuse that functionality across applications. That’s the idea behind microservices, and it’s an idea that Netflix is a big fan of…
Do #3: Do hire a ScrumMaster and apply Agile Methodologies
Waterfall is dead. I talked about it in my first post here, but it bears repeating. Agile leads to functional software sooner, and allows for the program to adjust for changing requirements and priorities. I’ve been working in tech industry now for over 10 years, and I have never seen a project that knew all of its requirements up front and never wondered from them. I’m not saying it’ll never happen…well…actually, yeah, yeah I am. It won’t happen. So don’t plan for it to happen.
Oh, and don’t cheap out on the ScrumMaster either. There are places where corners can be cut, but the person who is guiding your project isn’t one of those places.
3 Don’t for your next IT Project
Don’t #1: Don’t build in isolation
It hasn’t worked for Hilary and her email server, and it won’t work for you. This thinking was prevalent in the 1990’s and 2000’s, but today, no system has all the data/information that they need. And unless you are Steve Jobs, you don’t know what your customers need. Get out there and interact with the users and systems of your community of interest. Do it before your techie’s fingers hit the keyboard…
Don’t #2: Don’t build to a specific technology
Technologies come and go. Technologies change. Building to a specific technology will only put your organization at risk of snowballing sustainment costs in the future as vendors will be able to jack up the prices to sustain retired technologies.
They have every right to do that. They will do that. And you will not be happy. So, don’t build to a specific technology. See “Do #1” and build to a standard…
Don’t #3: Don’t micromanage the build
IT people aren’t creative in the traditional sense, some aren’t anyway, but they can certainly be creative when it comes to solving problems. Let them! Outline what you need in broad brush strokes, and let the IT team fill in the rest. You are employing them to be smart, so let them be smart. Let them use cool new techniques and methods. Let them enjoy their job. Who knows, maybe by doing that, you’ll be able to keep them for longer than the 4.6 years people are currently staying…
So, that’s a quick guideline of Do’s and Don’ts. There are more out there, and if you can think of any I missed, myself, and probably other readers of this post, would love to hear about them in the comments. To my readers in the DC area, stay dry. I hear we have a wet one coming our way. And I’ll chat with everyone again next week. Thanks for reading!
Steve Palmer is part of the GovLoop Featured Blogger program, where we feature blog posts by government voices from all across the country (and world!). To see more Featured Blogger posts, click here.
Great stuff! Please may I humbly second these views. Which agree well with my experience in IT and dissemination.
Oh Mark, don’t be humble if you are agreeing with me 🙂 Thanks for reading!!