Intended audience
Throughout my career, I have continually tried to improve my project management skills. For large organizations, there are extensive options for improving project management processes. I always find it challenging to find concepts that can be applied to smaller organizations. This article is intended for smaller organizations that have the following characteristics:
- Less than 1,000 employees
- Annual budget of less than $ 50 million
- Project teams that typically have less formalized project management processes
- Project work that often starts without a great deal of scrutiny or planning
- IT staff that have broad (rather than deep) responsibilities
- Project staff that usually have operational responsibilities in addition to being part of projects
(This tutorial is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)
Background
At some point in every manager’s career, they reach the point where they move from being a project resource to being a project manager. I am not referring to the formal definition of a project manager from a PMP point of view. Rather, I am referring to the point in time when you are responsible for your first project that is more than a one-person team.
I, like many of you, am in constant pursuit of knowledge, training and professional development. When I encountered my first project, I naturally turned towards formal project management training. I took classes on project management tools, read books on project management, and attended free (and paid) project management classes online.
After doing all of this additional professional development, I expected to be more capable of managing projects. However, despite this new knowledge I found myself still woefully inadequate when it came to managing what I considered large projects.
Why?
I learned a great deal about project management. I learned about project charters, generating a work breakdown structure, project risk and change management. I even dabbled in different project management methodologies thinking I just needed to find the right one that would work for my organization.
What I did not learn however, is how to scale down project management methodologies to projects that are big to the organization but have small staff to complete them. This article is intended to be a first step in helping you adapt project management practices to smaller organizations.
The process is more important than the system
Small project management is difficult, and there are very few guides to get you started. Because of this, you will have to learn to adapt existing methodologies to what works for your organization. I highly recommend a starting small and then growing your project management process.
Start with an easy item. A project naming convention is a good place to start. Having official names for your projects ensures that everyone is talking about the same project (including any vendors) that may be assisting. For example, if the server team calls a project the Active Directory Migration, you do not want the leadership team calling it the Network Renaming Project and your vendor calling it User Account Provisioning Project. I have seen more than one project get placed on hold because a lack of consistent naming caused the financial accounting to be inaccurate.
Quick Tip: Use a numbering scheme to go along with your project name. I like using the YY/MM/DD for when a project started as the project number. That way regardless of what system you use, you can quickly sort projects by their original start date and archive old document folders. Ex. 170528-ActiveDirectoryMigration. A project number also always gets around any “nicknames” that come up during a project lifecycle.
Next, pick a financial threshold and require a simple project charter for all projects over that threshold. This will allow your small project team to begin relying on a more formal project approval process without overburdening them with change. I also find it helpful to start with a short one or two page charter for the first few. It is always better to modify the charter template later when you need additional information for the next project. Small teams can be extremely frustrated with the collection of data that is never used. Also in this stage, stick to unstructured documents while you work out the process. Basic word processing applications and spreadsheets will work just fine.
After getting a basic approval process in place, begin regular project status reporting to the relevant stakeholders across the project portfolio. Small project teams usually have more than three-four projects, so it is important when giving status reports to stay at the 10,000-feet view. Simple Red, yellow, green and budget status for each project is sufficient.
By now, you are probably asking, “When do I need a project management system?” I suggest having the following in place before looking for a project management system:
- A formalized project opening and closure process that requires a project charter / plan
- More than two people performing project tasks
- A regular reporting cadence with management
Once you have those three things in place, selecting a project management system becomes much easier.
Just about any project management system will work, but ITSM Integration is ideal
For small project team, any simple project management system will usually work just fine. However, in an ideal scenario, a project management system is integrated into an IT Service Management system. Oftentimes what comes in as a request can grow into a full-fledged project. Being able to associate the initial customer contact (and corresponding communication) can be vital to a projects success and understanding the initial intent. Have you ever wondered, “How did this project get started?” ITSM integration can oftentimes provide the answer to that question.
Be a taskmaster
Perhaps the most difficult part of managing small project teams is knowing the difference between a project and a task. You can find several explanations of the difference between projects and tasks on the internet. However, I run small project teams using the following definitions:
A Task is a work activity lasting more than one workday with a defined output and must be completed within a specific timeframe.
A Project is a collection of interconnected tasks that achieves a specific product, service or result. This is a modified definition of the Project Management Institution definition, which defines a project as “temporary endeavor undertaken to create a unique product, service, or result.”
In order for small project teams to be successful on large projects, the project manager must at all times know the status of project tasks, and be ready to respond when obstacles to project success appear. The most effective way to stay on top of this is to follow the principle that “project reporting is part of the project task.” At some point in your career you will have someone who states, “I don’t have time to do my work if I have to keep updating my task status.” Work is not complete until the organization knows it’s complete. In other words, knowing that a project is complete is just as important as the work actually being complete. If the organization cannot leverage the fact that a task is complete, and move on to the subsequent work, then the task is not done.
A small project manager must also be incredibly diligent in controlling project scope. This can be especially difficult as task assignee’s often have much more freedom of decision in their organization than their peers in large organizations. Additionally, formalized change management processes can be overly burdensome in small teams. It is imperative for the small project manager to keep task duration to one week or less and diligently monitor any past due items. Task lateness is oftentimes a symptom of scope creep in smaller organizations.
Keep the Process right-sized
As your small project management process improves, it will inevitably get more complex. To ensure that complexity is appropriate (and actually helps drive project success) consider the following ways of categorizing your projects.
- Small Projects – These can easily be tracked just by getting updates without a formal WBS. Things like buying a new plugin for WordPress could fit in this category. Another example would be “Have all staff members complete mandatory training.” Typically, projects like this can have flexible completion dates.
- Charter Required Projects – These are projects that need to have some level of approval other than the first line manager, but do not involve significant financial investment. A summary of major deliverables / milestones are usually sufficient for management approval.
- Large Projects for small teams – These projects usually involve a significant time and/or financial investment for the team. Somewhere around 40 hours of work with more than one team member and 25k or more in expenses are a good fit for projects like this.
Be sure to keep the documentation appropriate for the size of the project. Also if a project grows, don’t be hesitant to stop and say, “This project has grown to be larger than we expected, it’s time to get the appropriate documentation in place.”
Relationships, Relationships, Relationships
The most important part of managing big projects with small teams is to establish meaningful working relationships across the organization. Small project teams usually have broad rather than deep skill sets. When troubles arise, the successful project manager must be able to look across the organization and seek assistance where it can be found. Having a good relationship with key leaders in the organization can help you quickly overcome most obstacles.
It is equally important to have excellent relationships with your vendors. If you are easy to work with and your vendors like working with you, it becomes much easier to ask for a favor when needed. Having the ability to call external resources and ask a quick question can mean the difference between completing a task on time and it being late.
