First off, what is project planning? In a nutshell, the process of planning is the creation of a roadmap that the client and the team agree to follow to get the project from point A to point B. It’s a benevolent human intention to look ahead before the jump. And in a way, it’s an attempt to impose control over something yet uncontrollable.
Makes perfect sense. You have to approach the task from somewhere so writing things down, structuring them, putting it on a timescale is an intuitively right thing. Like a movie needs a script, a project needs a plan. However, a plan itself is a hell of a task for a project you don’t know much about yet.
Adopting Development Methodology
The high-level understanding of how a project is going to be built is an obvious prerequisite. Depending on the methodology you adopt, a project will either gain momentum and essentially build itself, or become a crab bucket with issues intertwined and stalling the progress. Here’s the Toggl’s perfect way to explain the most common software/application development methodologies.
These are based on the real-life evidence of how things usually work but this doesn’t mean they go the way they’re planned.
Let’s look at the two gigantic ones. With a traditional Waterfall model, teams are mostly focused on delivering the X amount of functionality within the planned timespan. The Agile approach being sort of a “planning-on-the-loose”, is iterative, changeable, and often times self-managed planning.
This showcases the main antithesis: “Do teams work better when they see the beaten path and all their efforts are towards the execution on time, or would they be better off trying to find their own way to the goal which might be shorter?”
The Reality Of Project Planning
If you can recognize patterns, you can project how things might go, which creates the opportunity for planning. But how do you plan planning? Reality is, despite the rational and productivity-driven intentions,
Planning a project is nothing but building a sand castle.
Even though backed by the reality of previous experiences, every new project is a black box and assuming that it falls into the familiar model may play a trick on the team unfamiliar with the flaws of that model. Along with patterns come restrictions and resistance. Resistance is the enemy. Another reality is the proverbial mob mentality that we can fall victims of. If there are proven ways to accomplish things, why not follow them and be on the safe side that way? You take a successful project from the past and roughly run a new one on the old rails.
Any guideline has a set of constraints and by obeying a guideline, you magnify its constraints as well.
Being aware of what can go wrong is one thing. Taming creativity and open-mind thinking in favor of relative safety is a showstopper. And ultimately, if we accept the fact that planned time is not carved in stone and susceptible to changes, can we say this?
Planning with lines of retreat is planning just to check the box.
In other words, the value of a plan that no one is obliged to stick to is just disciplinary. In most cases, however, a PM is capable of creating a viable plan, even making a team follow it, but we are trying to figure out the practicality of it and ways to improve. I am not going down the indie road of non-planned development or hybrid approaches, let’s just assume planning matters.
Why IT Projects Need Plans
We need to understand that a web or mobile application development is a multifaceted process that we as technical performers and our clients as owners, see from the different angles.
One of the most important things about project planning is they help both parties stay on the same page.
This doesn’t mean that by effective planning we can only keep the client in check and avoid mid-project fundamental changes, but also pay attention to all the work done before the technical part. A sufficient plan covers all the aspects of the project, including marketing, sales, reputation, taxation, and much more than a developer’s eye can see.
Client Safety
If you convinced the client that you are capable of delivering a product they require, a few other variables arise:
- Time.
- Costs.
- Satisfaction.
- Process.
Vague answers like “from 2 to 8 months and $10K to $50K, depending on who knows what” is not even an option. It’s a client’s legitimate interest to know exactly what they are investing into. It’s not about trust, passion, and accolades, it’s about establishing a solid foundation of the project once and forever. For that, you better have some charts, graphs, tables, and numbers ready to go. This is the essence of planning.
Our Own Credibility
If a client can see the perspective and be satisfied with it, we have no chance to blow it. A PM has to keep track of the multitude of parallel and consecutive processes, deal with productivity issues, and watch the team not to be carried away while being open for discoveries.
On top of that, we have to observe the project budget, report progress, scale the features according to the planned timeline, and constantly pay attention to the quality of the deliverables. This is a system. And systems like plans.
How Good IT Project Plans Work
A good plan is more than just a list of actions with check-boxes next to them. It has to be a comprehensive documented vision of the client coded into the team’s abilities in relation to the costs and time.
- Sets the start- and the endpoints of the project with a clear definition.
- Segments the bulk of processes into tasks and assigns specialists.
- Sets the pace of the project and defines the deliverables standards.
- Helps leverage specific aspects by monitoring the resources.
- Provides a clear indication of progress for non-technical clients.
- Reflects the project progress for other teams to pick up effectively.
A client has to be involved with the project plan in its entirety, not just the final phase. Product owners have to know our approach, advocate it, and realize its limitations and abilities. A healthy plan helps avoid misunderstandings, inflated expectations, and the “us-them” perception issues.
How To Plan Projects Like A Pro
Being a hell of a PM involves planning skills second to none. From our experience in building different caliber products with different success rate, here is what we’ve come to:
- Starting off, there is barely any information. Roughly document the high-level structure of the project and map out the stages you understand.
- Remember the blank spots of the project. They may contain some iceberg-like features. Be generous in the evaluation of risks and economical in terms of resources.
- Keep processing information. The more detail you manage to pick up, the more precise your project stages will be.
- Don’t leave features unaddressed. Create an environment for the team to estimate on something.
- Double-check the team’s estimates. There have to be no black boxes in their estimates, don’t guess – ask. Your understanding is the client’s understanding.
- Be prepared for things to go not the way it’s planned. Leave space for amendments. Make the client understand that on a large scale too.
- Have a Plan B.
- And a Plan C.
- Regardless of what the project encounters during the development stage, it has to make a strong finishing statement. That is no slack on testing and deployment. Think deadline beforehand and allow some time for the release polish.
- Stay on track after the launch. Make sure product release provides an opportunity for your growth. Analyze the progress, the repercussions, and how your expectations and prognosis stood against the real-life test.
Conclusion
The problem of planning for the sake of planning is part of a bigger issue and it is the “pathologic busyness syndrome”. For some reason, people believe that fast and messy process is the display of “work” that inevitably lead to better execution. So often times people tend to stick to the ceremonials of the process instead of trying to find ways to optimize it.
Planning a project becomes that ceremony. Whenever a project is put on the map without a proper study, iterations, and freshness to it, it falls into a category it was not initially intended for. It get’s worse when the same mentality applied for planning, infiltrates into the development methodology, user stories, and implementations.
We stand for meaningful planning, relevance, and smart prioritizing. Planning does help a project unfold to the best of its ability, but it doesn’t have to be an imposture, another line in the quote, or a means to buy time before you get your bearings.
