Goals should drive the process
In 2017, we've successfully closed 110 projects to date. In 2016, we closed 102 over the entire year. How do we define a "project"? Common traits include:
- Any task that will take two or more resources two or more days to complete
- Any task that makes a change to an environment (new software, hardware replacements, office relocations, etc.)
- Any task that requires our coordination of services of a third party (wiring installation, contractors, software vendors, or similar)
One client, who is over 5X the employee size of Innovative, recently pointed out that of all their 2016 initiatives, they had successfully completed exactly two. A prospect stated that while they excel at delivering upon their core business functions, they can't so much as change a coffee vendor without sub-committees being formed, months of meetings scheduled, and what seems to be an act of congress. Each inquired as to what I thought was our "secret-sauce". How is it that we are able to get projects through to successful completion?
Our key to project management is to have the goals and milestones drive the process, and not require the process to deliver the goals.
Quite often, we are asked to provide a detailed Statement of Work document outlining all of the steps necessary to complete incredibly complex installations. If the time is taken to prepare an 11-page SoW, I will guarantee that by page 3, the rest can be thrown away because we will uncover some related issue that has to be dealt with either in parallel to the tasks, or that will require a different approach than planned be taken to remain on schedule.
Working to a defined plan is important, however, the difference I'm suggesting is that the level of detail of the plan does not often have to be as specific as many believe. If qualified resources are engaged to complete a project, one of the greatest skills they'll bring is nimbleness to address unexpected challenges that will surely be encountered along the way. A McDonalds-style operations handbook is great for highly repeatable, highly predictable set of processes, but given the variability of IT projects, the same level of detail would only serve to bog down the implementation process, as constant revisions would prove necessary, causing the dreaded "paralysis by analysis".
In contrast, our SoWs will typically state the desired outcomes of the project, and break down the processes toward the outcomes into phases or stages, often marked with attaining key milestones. However, the details of the steps required milestone-to-milestone are typically not provided, because there may be multiple ways to get there. We find that rather than spending all our time reading a map and documenting our planned route, it's much faster to start driving and leverage our GPS to route around barriers quickly and get us to our destination via the quickest route.
In this analogy, our GPS is constant feedback - we have regular Monday project planning meetings, where key outcomes for all open projects are discussed and agreed upon for the coming week. During the week, our project manager, Doug Bunnell, conducts regular touch points with project leads, clients, and vendors to be sure all tasks are remaining on track, and if not, to help contingency plan to be sure milestones will still be met. First thing Friday morning, we then have a project update call, where we review all of the key milestones we had set out to attain that week to ensure we will complete the week in the position we had planned. After all, you get what you inspect, not what you expect, so quick touchpoints keep us agile while focused on the big-picture milestones and goals.
Many of these concepts can be found in what's known at the Critical Path Method (CPM) of project management. If you're interested in discussing project management further, feel free to reach out - as you can tell, I love this stuff!