Life in information technology can feel like one big project that never ends. It can also feel like the types of assignments are non-stop, with life moving from one job to the next. The hamster wheel feeling is no doubt valid, but we should take a step back to help us understand what type of work this is. No matter how well you plan and prepare, IT project management finds ways to be a bumpy road.
Like Allstate’s Mayhem character, trouble has a way of finding you. However, claiming Murphy’s Law as the rationale for anything going wrong is no way to live.
What is a project?
The Project Management Institute (PMI) is the global leader in advancing this profession. They define a project as follows:
PMI defines a project by its two key characteristics: it is temporary and undertaken to create a product, service, or result that is unique.
CASE STUDYThis Wisconsin manufacturer needed to modernize its IT infrastructure to support rapid business growth.
Discover what they did
By definition, could we say that every Help Desk ticket is a project? That ticket is considered to be temporary – you no doubt have standards around ticket response times and targets for closing out tickets. While that explanation may satisfy “temporary,” I believe a reasonable person may find a Help Desk ticket to be the shortest project ever. Now let’s take on the second half of the definition – create…something…that is unique. Many tickets can be unique, but that tends to be based on end-user skill sets or situations based on the role(s) they serve.
For some in IT, life can literally be a never-ending conveyer belt of work – hammering out temporary, unique product/service/result for the organization. In other cases, IT project management is a seasonal effort based around the ebbs and flows of your organization.
There needs to be some structure in the focus of the work, planning of operations, real-time reporting. It doesn’t take much for jobs to get sideways with a lack of focus and discipline. As a manager, it’s your duty to keep a keen focus on what was agreed on to be done and the cost. There will be unavoidable issues that need to be resolved, but the majority of issues I’ve seen in management have been from an overall lack of discipline in managing the work.
Projects aren’t easy to plan or manage, that’s why certified professionals make more than their colleagues with similar experience. This blog post isn’t here to re-write those standards. What PMI and CompTIA have already done is laudable. Not every organization has the tolerance for all the steps laid out by these professional organizations. Sometimes you need something more efficient.
On the back of a napkin here are major (in my mind) considerations for mapping out a project:
- Planning
- What is/are the main outcome(s)?
- Who is responsible for different parts of the work?
- How long will the work take?
- Tracking
- What has been done?
- Where are we now?
- What’s next?
- Reviewing
- What worked?
- What could have been done better?
Planning in IT project management
PMI would call outcomes and responsibilities part of the Charter. The Charter is a document that makes the case as to why you’re going about the project and who is going to do what. Once a job gets off the skids, I’ve seen many instances of staff asking “wouldn’t it be nice if…” which leads to scope creep. If there is no set scope for the project or someone willing to say “no,” time and budget will get out of hand. I remember one security camera project years back, seemingly every other day during the work I was asked “well we could add this” to make the job easier. It was an easy answer because if it wasn’t a part of the original scope of work, it wasn’t happening.
Another project we took on many years ago was to install a new SAN for the organization. The business-critical apps for the organization, along with domain controllers and the VOIP phone system ran on it. The legacy SAN was past support and struggled to efficiently run the business-critical database apps. The Charter was to get our data on a new storage solution that was
- Supported
- Sized and configured appropriately for use
- Able to reliably support the database apps
We tackled all of those items when we installed the new SAN. The charter made it an easy sell because business-critical apps need to be housed somewhere where you can get support for the hardware if need be and on hardware that can reliably run the databases.
Another valuable step in planning your strategy is lining up who is in charge of what. The last thing needed as a job shoves off the dock is for anyone to say “I thought that person was going to do that.” A great tool to manage who does what is a RACI Chart. RACI (Responsible, Accountable, Consulted, Informed) Charts can help divide and conquer the work and lines of communication.
Tracking
Personally I like to use a physical Kanban Chart in my office to track what is going on in the project. I like something that’s analog, that can’t follow me home to obsess over. I break down the work into four categories – TO DO, DOING, TESTING, COMPLETE. It always feels good to physically move those cards over to COMPLETE, but I don’t leave them up for more than a day so I’m not dwelling on the past.
For team management, a Google Spreadsheet will do in terms of tracking what has been done. In the past, the team I belonged to had to turn around about 400 laptops in a short amount of time. Each day was a simple check in on how many laptops were imaged that day:
Monday | Tuesday | Wednesday | Thursday | Friday | TOTALS |
50 | 40 | 65 | 50 | 65 | 270 |
Monday.com, ClickUp and Microsoft Project are all wonderful tools that can really help make things easier, but the key thing is to have someone keep track of the work as it is happening, regardless of which tool you use. Not every step in the process will allow clear timelines to communicate out, but when someone asks, you should be able to show what is planned, what has been done, and what’s going on right now. Anything else may look like chaos to an outsider. It might not seem like chaos in your head, but often perceptions matter.
Project review
Everything is important, but the Review – or Lessons Learned as it is called in professional project management standards – is significant. In a perfect world, everything will go as planned, but we don’t live in a perfect world. Something will happen, it’s important for the reasons why to be tracked, so later on the big picture can be reviewed. The spirit of a review isn’t to point fingers or lay blame. It’s about getting better. It harkens back to continuous improvement structures, asking staff “what worked” and “what could we have done better?” If you are looking at a Plan – Do – Study – Act, this would be the “Study” in the process.
Finally, I’m curious about what you do to manage a project? This is a review of what works for me, but it certainly isn’t a list of things you MUST do. What tools do you use? Do you focus on different aspects of IT project management? I look forward to reading about your experiences.