Milestones, to-dos, communication, deliverables. These are sometimes shouted out as the end-all solution to poor project management. However important these tools and methods are, they’re just tactics. What’s really needed to manage an effective web project is a plan and strategy.
Differentiating between tactics and strategies can be difficult at first. A strategy is an overall goal; something you want to achieve. For most, a solid project strategy would be the successful completion of the work and the satisfaction of the client. Tactics are the tools and methods you employ to make the strategy’s goals attainable. For example, proactive communication is a feasible tactic for the strategy I outlined.
You might be thinking the strategy is a piece of cake. Who doesn’t want to complete a project or end with a happy client? But having a strategy in place is just the first step. You need a plan to implement that strategy. Therein lies the hard part.
Planning, like nearly all proactive tasks, requires discipline. You need to sit down, turn off distractions, and concentrate an immense amount of attention to details you wouldn’t normally consider in your day-to-day project activities. Once you’ve nailed down a plan “template” that you can start each project with, the process becomes easier. However, each project is going to have unique requirements that you’ll have to analyze in order to flesh out the meat of your plan.
Do project plans need to be written documents? No. But there should at least be a known process that unfolds almost naturally with your projects. For instance, you should know that the first step in your project is to have a call with the client, and you should know what sort of information you’ll need to gather from them. Furthermore, you should know what the steps take place afterward so that you can think ahead to step three or five or twelve, and connect back to the first step in case there’s a special issue the client will need to address. This is proactive planning.
The problem we fall into with poorly planned projects is a lack of foresight. We find out toward the end of the project that there’s a much simpler solution to a problem that could have been discovered by connecting previous steps. If you know one of your projects steps is going to involve database integration, use that knowledge to ask the right questions in the first step.
Written project plans are obviously desirable, although not every project is large enough to merit the effort. In most cases, a straightforward scope of work document (or spec sheet) coupled with an in-depth listing of planned project milestones is all you need. Bigger projects will ideally have more substance such as mission statements, goals, capabilities, team members, and so forth.
Spending that initial hour or two at the beginning of projects to understand and plan for the coming challenges is an investment. Over the lifespan of the project, you’ll see that investment grow in value. Use your time wisely.