Starting a new project can be nerve-wracking. You have to account for what the project is, who has to do what, what the timeline looks like, and how to make it all a reality. It doesn’t stop there, you also have to account for changes in scope, bugs, things not working as expected, budget changes, and more. The entire process can be insane even with a plan.
I used to get insanely stressed out standing up a project since nothing ever went right, but that largely changed once I learned how to plan properly. I have worked on both coding projects and implementation projects. Despite both types of projects being largely different, the general process remains the same. The other thing to remember is that no plan survives contact with the enemy. You will change your plan at some point, but it doesn’t have to be (that) stressful.
To stand up a project you need to first define it. What is the project and why is it being done? Next, you need to define a scope. What is it defined as, what will it do, and what will it cost? Once you have the limits for the project, you can begin to divide the project up into smaller projects to assign out. Figure out the dependencies using something like a Gantt chart and determine the order things need to be done. As you split each part up, you can adapt to changes as they come without harming the overall plan and purpose.
Defining the Project
To begin any project, you need to define it. Defining a project doesn’t just mean something like “we’re building an application to let people meet and date.” You need to drill down and define what specifically the product or project is aiming to do, how it intends to complete it, and why you’re bothering.
If you’re building a dating app, who is the target audience? How will you attract them? What is the algorithm you plan to use so that people would rather use your app? How will you monetize it? Why are you making a dating app when there are so many on the market? These aren’t meant to be critical questions, but you need to be honest and thorough with each one so you know what you’re doing and why.
Ideas are a dollar a dozen, but a fleshed out idea ready to go is substantially rarer. If we’re building a dating app, are we targeting something like Match or are we heading more towards Tinder? How much of each are we targeting (if any)? Drill down and drill down again.
Drilling Down on the Definition
You want this to border on being a business plan. “We’re looking to deploy this software across 20,000 computers, and we plan to do it in stages by first testing on unessential and redundant machines (in list a), then we will move to low impact machines (in list b), then we plan to move to moderate impact machines…” This is just what goes into the “what” part of our definition. It’s also not written in stone, but it is a way to have a plan to begin scoping the project out fully and for how we divide the project resources up down the line.
Why are you doing it? “This software is being deployed as part of our contractual obligation to deploy security. We need to make sure we have a 90% deployment rate by cutoff date a, then we need to go through and find a list of the stragglers to supply to partners by cutoff date b. This is why we are approaching the project in the order mentioned before. We are doing it at this rate due to the fact our clients are working towards compliance.”
What and why need to be answered thoroughly. What you’re doing will be affected by why you’re doing it. In our previous example, we were deploying security software, so we went off of lists of specific agents to push through faster. We reduced testing (instead of a single agent at a time) because we need to deploy for compliance. If we were going for the lowest client disruption, we might approach a single agent at a time after hours to study the environment. Defining our project helps define what we are doing and why so that we can scope it out. There may be more than one way to accomplish the same task, but you need to pick the one that best fits what you’re doing but also why you’re doing it.
Define the Scope
Once we define our project we have to plan a scope for our project. We know what we’re doing and why, but what are we going to do and how far do we go doing it? If we get a feature request, should it be acted on? There cannot be gray areas with the scope of a project (or team). Otherwise, you set the whole thing up for failure.
Scope out the specifics of the product. For our dating app example, we would want to plan features and use cases. Are we going to spend time on features for people over 60? Will this app support 2FA? What kind of database are we using and what scale can it handle? Are we using a single server or a cluster? AWS or bare metal? What will we do if we hit the cap of our original plan? How much is all of this going to cost in terms of work hours and actual costs? Scope your project for where you want it to be finally and build accordingly.
You’re going to change your mind about things, or have your hand forced. If you scope sanely in the beginning, you set expectations properly and won’t be blindsided (as much). For our security software deployment example, what do we do about agents which are broken (OS level or similar)? Who has to fix those? That depends on the scope. Eliminate the gray area before it’s a concern.
Divide the Project
I divide my projects into several conceptual divisions. I have phases and units. Phases are the rough divisions of what we’re doing to satisfy a goal in the overall plan. They break out into something like the planning phase, the design phase, the implementation phase, and the finalization phase, and then they further drill down on each so we can build meaningful metrics at each step. We have preparatory planning to lay the groundwork, implementation planning to plan the actual implementation, budgetary planning to plan the financial or resource situation, etc.
Units are each discrete task which goes into the whole. What are we building or what are we doing? Preparing an environment is a unit even if it might fit between phases. Implementing a feature may be an individual unit in a specific phase. Some units are even their own projects. Phases and units are different divisions of the same whole. The districts of a city will vary from the zip codes because they each have a different purpose.
Phases
When you split up a project, you want to have various phases focused on different stages of the project. Phases are more rooted in the goal of what we’re doing rather than the individual actions we take. As such, a phase is temporal rather than practical. In earlier phases, you’re concerned with planning, in middle phases, you’re concerned with doing, in later phases, you’re concerned with verifying what has been done and shoring up remaining work. You can still do practical actions while planning, you can still do planning while doing, and you can still do either while verifying. The phase is concerned with the trend of your actions and the goals behind it rather than what is actually being done.
Units
Phases are temporal and units are practical. A unit is a division of each individual task itself. Writing boiler plate code during the planning phase is a unit of the project. Implementing a new login system is a unit. Every practical action is an individual unit. Some units can be further divided into smaller projects which then need to be split out into their own phases and units.
As you get larger and larger projects, it gets more likely you’ll have sub-projects to plan as well. Treat these as a unit in the whole (unless they constitute a whole phase), but also as a separate project. Do the same thing for each individual group of tasks. Even a large project is just a compilation of smaller tasks and units which add up to the whole.
Order of Operations
As you learn to divide your project into both phases and units, it gets easier to know what order operations should go in. A technical resource which has no bearing on the planning phase can still be tasked with working on individual tasks unrelated to planning. There are units which are necessary, but which don’t really have a bearing on the given phase.
One of the best ways to divide up a project once you know what needs to be done (and in what order) is to draw up a Gantt chart. A Gantt chart is basically a way to order units, or tasks, into the order of operations necessary to complete the project. It gives you a visual representation that B comes before C, but A comes before either. Some of these units will span entire phases, so the earlier they can start (and end), the better.
Figure out what tasks are necessary to unlock other tasks. You have to plan before you can implement, and you have to write boilerplate code before you can write the fun stuff. The boilerplate code is going to be essential, but how much actual planning do you have to do to know you need a user logon page? The boring stuff will hold you back if it’s not done, but with a little planning, it’s easy to know what you need to do first.
The more you plan, the easier it is to order tasks based on what bottlenecks what. Your planning phase holds up your implementation phase, and your database unit holds up your user customization unit. The order of operations must be understood and implemented properly to keep up with timelines and budgets. The more efficiently you plan before you need to hire extra resources, the more money you will save with the increase in efficiency in each individual task. You can’t just fire a team for a week because you screwed up on the order of their prerequisite to working.
No Plan Survives Contact With The Enemy
No matter how much planning you do, it’s going to hit snags. I spent over a week planning a basic security software deployment to over 20,000 agents only to have all of my planning trashed within a month of actual work due to external reasons. It’s going to happen, and if it does, you’ll be glad you planned originally.
Despite throwing out my actual plans, the whole act of planning made me think about the entire process differently. I had to look into every single aspect which I needed to account for. When things went awry, I rolled with the punches and everything worked out with minimal downtime.
The more you plan, the more you have to know in advance, or the more you know you don’t know in advance.
Either way, you clear up the unknowns. Parts of the process were outside my control and they went awry. By accounting for every single thing I could within what I had control and access to, I made the downtime minimal despite everything blowing up. Analyze the situation and prepare for things going wrong in advance.
Make sure to build extra time into any plan. It’s easy to over promise and under deliver, but much harder to under promise and over deliver. I much prefer the latter. You look like a rock star and even if everything blows up, you have set a more accurate expectation from the get-go which is easier to work around. Plan for things to go wrong and expect for timelines to get warped, especially around bottlenecks. Sometimes the whole plan blows up because someone (above your pay grade) demands a new feature out of scope. The more you build in buffers, the more flexible your whole plan can be.
Triage and Emergency Planning
Sometimes stuff just goes wrong. You need to be able to triage the situation and plan for how to rectify it without causing issues to your overall process as much as possible. Can you spare resources? Have you built in extra time? Can things be scrapped to afford the resources to fix what’s pressing now?
You have to be able to triage a problem. A manager complaining about a minor feature missing is going to be nowhere as important as the system going down or a C-level demanding something. What about if you find a catastrophic bug right before production? React accordingly.
When an emergency comes up, you should have some plan in order. Who is working on something which doesn’t matter that much for this phase? Who is working on something which isn’t a bottleneck? Pull them off if they can be made relevant, or use them to cover spots so that you can shift resources to fill the gaps. Plan this before you have to figure it out on the fly. You want there to be some overlap or else you run the risk of learning about bus theory firsthand.
Bus theory is the theory of: What happens if a key employee gets hit by a bus? Are you screwed or can you power through? Ideally, it should be an emotionally trying time, but shouldn’t affect business. Make sure that if you don’t have backups, you have documentation so that new resources can figure it out. Plan around any key employee going missing without major interruption.
Managing a Project
Hopefully this gives you good direction for the next project you manage. Managing a project can seem easy until you get into every moving part which can go wrong (which tends to be all of them). Plan for things to go wrong, and plan for what you need to do at every step. Learn to make a Gantt chart (or whatever works for you) to figure out where your bottlenecks are. No plan is going to be perfect so learn to adapt as you go.
Work on dividing tasks, then divide them further. Split your project into general phases and individual units which need to be completed. Think of it like systems and components. A system can be made or touch on multiple components at multiple levels, but a component is a component.
If over-planning doesn’t work for you, don’t do it. Find your style of managing a project which doesn’t conflict with its success. Some people think fast on their feet, others need a plan.
Project management doesn’t have to be nerve-wracking, you just have to know what and why the project exists and how to make it a reality. Planning and implementation are their own skills which require their own trials to fully master. Try applying these tricks to even the most trivial projects and you’ll find that even small projects get substantially easier.
Feature image by PublicDomainPictures from Pixabay