Project management is usually described with thick books, certificates and abbreviations of three or four letters. All of that has a right to exist, but I have noticed a strange thing: many people who have read those books still fail projects, while some who have never read a single one run them brilliantly. So the essence is not in the terminology. It is in a few simple basics that you need not to know but to feel in your bones.
Over my years in development I have seen hundreds of projects: small and huge, successful and catastrophic. If you boil all that experience down to the foundation, there are not that many principles. I will try to describe them without the academic dust.
A project and a product are not the same thing
The first thing to understand: a project is a temporary undertaking with a beginning and an end. It has a goal, limited resources and a date when it must finish. A product, on the other hand, can live for years. A project creates a product or a part of it, and then it ends.
The difference seems formal, but in practice it is huge. When people confuse a project with a product, the project never ends. It turns into endless refinement where something new is added every week, the budget leaks, and the word "done" is never spoken. A good manager always knows exactly what will count as the end of the project and defends that boundary.
The triangle you cannot cheat
Every project rests on three parameters: scope, budget and time. I call this the project triangle, and it obeys almost physical laws. You cannot change one side without affecting the others. Want more features? You will need more money or more time. Want it faster? You will have to cut scope or hire more people, which again means money.
Imagine a tightrope walker whose balancing pole hangs on three ropes. Pull one tighter, and the other two will sag or snap. Most conflicts in projects come from exactly here: the client wants all three ropes pulled to the limit at once. More features, less money, faster. That does not happen, and a manager's job is not to promise the impossible but to honestly show what will have to be sacrificed.
There is also a fourth, hidden parameter: quality. When the triangle is overstretched, quality is the first and least visible thing to sag. Deadlines met, budget kept, features in place, and a month later a stream of bugs begins. That is not saving money, it is a deferred bill.
Project phases
Every project goes through similar phases, whatever different methodologies call them.
- Initiation. Why we are doing this, what problem we are solving, how we will know we have succeeded.
- Planning. What exactly we do, in what order, who does it, for what money and by when, what the risks are.
- Execution. The actual work, the longest phase.
- Control. Runs in parallel with execution: we compare plan with actual and react to deviations.
- Closing. Handover, acceptance, a review of what worked and what did not.
The most underrated phase is the first one. People want to start doing something as soon as possible, and the question "why" seems obvious. But I have seen projects that brilliantly delivered everything planned, only to discover that nobody needed it. An hour spent on "why" saves months of work on something useless.
The second most underrated is the last one. The project is delivered, everyone exhales and goes home. Yet the retrospective, where the team honestly says what went wrong, is exactly what makes the next project better. Without it, a company steps on the same rake for years and is surprised every time.
Risks: the umbrella you take before the rain
Risk management sounds boring, but it is one of the most practical things in management. A risk is something that might go wrong. Not necessarily will, but might. A key supplier delays a delivery. A programmer gets sick at the most critical moment. A third-party service changes its terms. The client changes the requirements mid-project.
A good manager lists such risks at the start of the project and, for each serious one, thinks through what he will do if it happens. It is like taking an umbrella when the sky looks gloomy. You may not need it. But if it rains, you will be the only dry person at the bus stop.
And always build in a reserve of time and budget. Not because the team is lazy, but because every complex project has surprises. A project without a reserve is a project that will definitely be late, you just do not know yet by how much.
Communication is half of management
If you ask me what a project manager spends most of his time on, the answer surprises beginners: communication. With the client, the team, contractors, management. Projects rarely fail because of technical problems. Much more often they fail because people misunderstood each other and did not notice for a long time.
That is why basic communication rules matter more than any methodology. Agreements are recorded in writing. Everyone knows where to find up-to-date information about the project. Bad news is reported immediately, not when it can no longer be hidden. The client gets a regular, clear status rather than silence interrupted by panic.
Where to start
If you are just starting to manage projects, do not try to master every methodology at once. Start with three things. Write down the project's goal in one sentence and the criterion by which you will know it is finished. Draw the triangle: scope, budget, deadlines, and honestly decide which rope can be loosened if necessary. Make a list of the five main risks and come up with a plan B for each.
At Ingello Systems we start every client project exactly like this, before the first line of code is written. After that, formalisation takes over a lot of the routine: when a system is described with schemas in Fractal, the scope becomes visible and measurable, and the triangle stops being a subject of arguments. But the foundation is always the same: understand why, how much and by when. Everything else is superstructure.
