When preparing a new IT project, it’s easy to get caught up in the development and testing processes. For a good part of my career, I was a software developer, and later a project manager, and at the time, that’s how I saw the world—a software developer always jumps right to a solution, and once that’s deployed, then you’re done! The project manager always looks and decides they need milestones related to deployment—how do you we get this solution out there and tested?
Now that I’m in a leader role, I see that all of those needs go back to communication and training, and in turn end up occupying a ton of time in projects. At Davenport University, we roll out many projects that end up being more about deployment and training than they are about crafting new solutions—here are three steps we follow to ensure a good deployment.
Lead time is key
When we’re starting a project, we have the communication and training discussion before we even move onto discussing production and planning the deployment. That’s totally different from how I used to do things from a developer’s perspective! Before, we’d figure out a project, decide upon a deployment schedule, and then figure out training and communication.
Now, everything begins with: What’s the go-live date? For Davenport, we’ll say it’s going to take a month to train everyone—which means we’ll need beta software done in time to train people, and we’ll need to communicate a need for trainers a month before that. Suddenly the entire project becomes focused on training and communication, instead of the steps for deployment.
I find the deployment stage is a little easier, anyway. Even if it isn’t, you reach a point where you can base your deployment plans around the training schedule—it’s much easier to map out deployment than to nail down a set training group. Learning this was an epiphany for me.
Use consistent language
The language in communicating with end-users always needs to be consistent. We used to just have our helpdesk staff post these communications themselves—”hey guys, we’re gonna be updating the wireless network over the weekend, it’s gonna be awesome!” Now we have the same writers—the same voice—for every communication that goes out.
They’ve got a voice for customers, a voice for internal staff, for varying levels of know-how. If nothing else, you should at least be keeping track of how complicated your language becomes, depending on the audience that you’re reaching. Beyond that, we make sure there’s always a calendar, blog post, or poster for people to check back with for details. If at all possible, having a person dedicated to managing this is huge—at Davenport, we’re fortunate enough to have an entire team for it.
Mind your users’ schedules
In turn, we try to have these communication discussions in the earliest possible stages of a project. If it’s an externally facing project, we try and back it up even further. Our lead time will vary from project to project, but you need to be mindful of the schedules and cycles that govern your end-users—being at Davenport, many of our projects affect students, so those projects are scheduled according to the school schedule, and accounts for holiday breaks and semester timelines.
We have a Google Calendar created specifically for project management, as well as a specific calendar for each individual members—that way, they’ll see those milestones in the context of their own schedules. Using that for your communications allows everyone to know what’s happening when. If you can’t dedicate an entire team to this, Google Calendar alone is a great tool for keeping people in the loop.
Brian Miller is the Vice President of Information Technology Services, Chief Information Officer, and Interim Dean for Online Education at Davenport University.
