Insights

Ten rules for delivering any project, from SAP rollouts to new GCCs

Most projects that slip do so for ordinary reasons: nobody wrote down what finished means, the people who care were not told early, or a trade-off was made silently instead of openly. Ten rules cover most of it, and they apply as much to an SAP rollout or a new capability center as to any other project.

The rules are from You've Been a Project Manager All Along by Anupam Shrivastav (2025), written from his work in project delivery and from teaching project management to postgraduate engineering students who are managing real projects at the same time. The explanations here are a short summary, not a substitute for the book.

1. Write it down before you start. A plan that exists only in people's heads is a different plan for each person.
2. Define what "finished" means, precisely. If the end is vague, the project cannot finish.
3. Identify who cares, and tell them early. Stakeholders who learn late become obstacles. Those who are told early become allies.
4. Break the work down until it stops being intimidating. Small pieces can be estimated, assigned and checked.
5. Map dependencies before estimating timelines. One late task can push several others, and the delay is rarely visible until it has multiplied.
6. Protect the one constraint that cannot move. Every project has three pressures: scope, time and cost. Usually one of them is fixed, and the others have to bend around it.
7. Make trade-offs explicit, never silent. When scope, time or cost changes, the people affected should hear it from you.
8. Monitor the real indicators, not the convenient ones. Report what shows whether the project is on track, not what is easiest to measure.
9. Close the project formally, every time. Hand over, confirm the result and record what was learned.
10. Learn the lesson once, and use it forever. Write down what you learned so the next project starts ahead.

Risks before they happen

The book recommends a risk identification session early, in which the team imagines everything that could go wrong over the life of the project and writes it down. It is an unpopular meeting. It is also the one that turns a surprise into a planned response.

Why it matters for SAP and GCC work

Large SAP programs and new capability centers carry the same pressures at higher stakes: many stakeholders, long dependency chains and a hard constraint, such as a go-live date or an audit window. The partners at Altacent Partners run programs as well as advise on them. See how a micro GCC is set up in seven days for the same discipline applied to a new team.