Welcome to the LAST of our 5 step plan. Our last post covered how to take a project from idea to definition. Now we’re ready to DO the work!
We’ve already performed an assessment, identified our top priorities, and delegated “low hanging fruit” (easy win) projects to staff. This last post will highlight implementation of a larger IT project, such as rolling out a new B2B ordering platform, performing an ERP replacement, consolidating data centers, or shifting infrastructure (for example, to cloud).
I also want to cover “selling” the project here, although it really warrants its own post. Selling starts as soon as you know the project is right for the company– and it doesn’t stop until the project is complete.
Selling the Project
The selling step is vitally important. If your executive peers don’t understand the corporate benefits of this technical project, you will find it difficult to engage their staff when necessary — and almost every large technical project involves staff throughout the corporation. If you sell the project correctly, everyone in the company will be willing to help it succeed. Even superman/superwoman cannot make it succeed alone — you can’t either, so don’t even try.
The first important step to selling your project is understanding the fundamental value it provides to the business. Remember, in order to get to this point, the project had to have HIGH business impact and/or HIGH risk. Your job at this point is to package up the business value into a project vision.
A vision statement should help communicate the project’s goals to employees throughout the organization. While each project may benefit from a different approach, agile management has some helpful steps to get you started.
After identifying your project vision, work on an elevator pitch that sums up the project and its benefits. Having this prepared in advance will allow you to pitch the project whenever asked — in a way that naturally ties back to your project vision, which ties back to the corporate benefits. Look for opportunities to speak to departments about this project, so that the entire organization has insight into why the project is happening and why it benefits the company.
Next, identify your beta team. Generally, the IT department will be the alpha team. I always like to create a beta team from outside of IT. The beta team should include a group of users who will be MOST impacted by the project. Not only do these folks provide valuable insight that your IT users may miss, but they also help SELL the project to their peers. The earlier you get them on-board, the better your chance of success.
Now have fun! Some projects benefit from contests and marketing events. I once rolled out a large sales rep ordering website to a pharmaceutical company , in an environment where the sales reps did NOT want this change. To get them engaged, we held contests (name-the-site, design-the-logo, etc), and we attended their national sales meeting to pitch the site. We had t-shirts and other give-away’s. Yes, it was an added expense, but it’s far less expensive than a failed project (NOTE: IT project failure rates are still high).
This step is simple: Do the work.
If you are fortunate enough to have a project manager on this project, decide on a communication plan up-front. How often will various groups (project stakeholders, department managers, users) be notified of updates? If you don’t have a project manager, make sure you understand PM methods enough to effectively run the project. There are many resources available online.
In my opinion, the two most important things about managing a project are:
Communication – It’s difficult to communicate TOO much.
Accountability – People will ignore things if they think you’re not paying attention. Set clear expectations and follow up.
If you are good at communicating and are able to keep people accountable, your project has a good chance of success.
The most rewarding part of my job is taking an idea and developing it into a completed and successful project. For large IT projects, this means focusing on the top-level, most-important things first — and not getting bogged down in the details too soon. I wrote about this particular concept previously, so I won’t repeat it here.
In our example project (the one we’ve been using through this 5-part series), our larger IT project is B2B ordering. Let’s list some of the resources here:
- Vendors/Contractors – I’ve found there are few large IT projects that are done 100% in-house (with success). A big key to my success over the years is pulling in the right resources to get the job done. More often than not, this involves finding the BEST from outside of the company. I’d rather work with an outsider I know can do the job (and ultimately succeed) than try to do it all in-house and fail.
- Internal IT staff – You want to include your internal staff, but you don’t want to bog them down in too many details too soon. Particularly if you have vendors/contractors doing any of the pieces — it’s often helpful to wait until the project starts to come together, so that your staff isn’t chasing possibilities that never become reality.
- Hardware/Software – If your project involves purchased hardware or software, do a test up-front. One of the best ways to minimize risk of project failure is to move any high-risk or highly-questionable or highest-priority parts of the project up front. In our B2B ordering example, if we plan to bring in orders via the software’s API, mock up a test and make sure you can actually create an order from the API before doing anything further.
When you think you’re ready, bring in the beta team. If possible, I like to roll out new tech to a limited group first, so we can get feedback, improve, then roll out to a slightly larger group, get more feedback, improve, etc. By the time you have it rolled out to everyone it’s a great experience for the users.
It seems like I’m missing a bunch of points, but I need to wrap up this post. Feel free to leave comments to identify all of the points I missed.