Over more than twenty years in IT, I have developed a set of “silver bullets” that can significantly improve a project’s chances of success. Some projects need only a couple of them; others require almost the entire set. Context determines which rules matter most.
In this article, I deliberately separate business and IT to make several recommendations easier to explain, although in a healthy organization they should not truly be divided.
Here, “business” means sales, service, marketing, and other operational functions. “IT” means developers, systems and business analysts, designers, testers, and the rest of the technology team.
1. Business First
Everything a company does—especially its projects—should begin with the needs of the business. If I could keep only one recommendation from this article, it would be this one. Business must be the driver of the project.
That sounds obvious, but here is the important consequence: if the business cannot explain what it wants at the start, accepting the project means that IT is taking on the role of the business. Projects in which IT tries to play that role rarely end well.
The team may spend months learning the domain and filling in missing decisions on behalf of stakeholders. In the end, the business often treats the result as something foreign: “Why did nobody ask us?” Resistance follows.
Should you refuse such a project? In most cases, yes. Otherwise, the likely outcome is exhausted nerves, team burnout, and a result greeted with phrases such as “That is not really what we wanted” or “Yes, but not in that form.”
When you are not sure, do not overtake.
2. Look Under the Rocks
Validate business requirements before rushing into implementation. I call this “taking the idea apart down to the last screw”: remove the decoration and determine what actually needs to be done.
TRIZ—the theory of inventive problem solving—offers a useful principle: the ideal system is a system that does not exist, yet still performs all its functions. IT should therefore ask how the business need could be satisfied without developing anything new.
Before implementing requirements, check whether an existing component, product, or process can be reused.
Just please do not offer another Excel spreadsheet.
3. Apply KISS
Software development has the excellent KISS principle: keep it simple, stupid. Do not introduce complexity without a real reason.
Complex systems tend toward failure. Build solutions that are simple but effective. Do not invent spacecraft, overload interfaces with unnecessary controls, or decorate a product beyond recognition. Build exactly what is required, and remember the previous rule.
A stone rarely breaks.
4. Do Not Switch on DRY
DRY—do not repeat yourself—is another useful engineering pattern. In code, reusing functions can reduce development time. At project level, however, a similar instinct can become dangerous.
Teams often see a new project as an opportunity to try a new technology or an innovative solution. That may be excellent for experience and résumés, but it puts the schedule at risk. New and untested tools dramatically increase technical uncertainty, especially when data storage is involved.
The safest strategy is to rely on proven technologies that you or at least one member of the team has already used in comparable conditions.
An old friend is worth more than ten new ones.
5. Grounding Saves Lives
A project manager should not float in the clouds. During requirements and concept development, stakeholders may throw dozens of wishes and additional demands into the project. The manager’s job is to separate the essential from the optional and identify the critical path.
Learn to tell the business, “Yes, but not now.” Do not ignore requests completely: record them and consider whether they can be delivered without disturbing the main route.
In plain language, do not build a spaceship when that is not your job. Narrow the project scope. Stay grounded—it really does save lives.
6. Define the MVP
This rule continues the previous one. Divide the flow of business requests into three categories:
- MVP: the minimum viable product and everything on the critical path.
- Nice to have: work outside the critical path that still provides clear value.
- Dreams: requests with vague requirements, no place on the critical path, or an unclear expected effect.
Explain this terminology to the business and agree on what each category means. Shared language helps align expectations.
7. Kill the Dragons
Old maps marked unexplored territory with warnings that dragons lived there. In an IT project, those territories are business processes.
When current and accurate process descriptions already exist, congratulations: you have a map of the project landscape. More often, projects begin without one. Secure the support of business analysts and ask them to start mapping processes from day one.
This is critical for validating requirements, identifying bottlenecks, and—most importantly—conducting user acceptance testing.
The more dragons you expose, the better.
8. Kill the Smaller Dragons Too
These dragons are smaller but often more dangerous. Business-process maps are useful, but descriptions of how people actually use the system—use cases—are invaluable. Begin collecting them from the first day as well.
Pay particular attention to how and why people use Excel. A spreadsheet often hides a dragon.
Involve a designer. The resulting interface will be not only attractive but also usable.
9. Build the UI with Agile Feedback
Initial interface requirements rarely match the final result or what users truly need. As users become familiar with a system, they discover new ways to simplify and improve it.
Show even the smallest interface changes as early as possible. Repainted a button? Show it. Adjusted the layout? Show it. Start interface design early and put it in front of users early.
Do not forget to collect metrics on how the interface is actually used.
10. Look at the End
Find out which reports will be required and who will use them. Determine where data must be exported, who will audit it, and how that audit will work.
Remember business and technical metrics, operational logs, and audit trails.
If you have time for only one of these, implement an audit trail for data changes. A single line showing who changed what and when can prevent hours of argument and investigation.
11. Deadlines Are Deadlines
This may be the most difficult rule. Business rarely likes the delivery dates proposed by IT, and IT rarely likes the dates expected by the business.
A practical guideline is to multiply the initial estimate by 1.5 when requirements are clear and by 2.5 when they are not.
These multipliers account for risk and unpredictable circumstances. Explain the arithmetic openly to the business. Do not try to hide it; people notice. Even these margins are often insufficient because pressure encourages teams to make optimistic promises and underestimate the real amount of work.
People do not write code continuously for eight hours a day. They become ill, take holidays, attend meetings, respond to emergencies, and work on other tasks. Estimates must reflect reality.
12. Deal with the Legacy
Few projects begin on an empty field. Existing systems and historical data almost always matter. Decide as early as possible what will happen to old data.
There are three basic strategies, listed in order of effort:
- do not migrate data;
- migrate only aggregated results or balances;
- migrate the complete historical dataset.
Not migrating anything is attractive from a workload perspective, but it creates a serious problem: users cannot see how familiar data will appear in the new system. Ten manually entered rows will not provide a representative picture.
In my experience, migrating summary data is usually the best compromise. Even when the business rejects production migration, move the summaries into a test environment and show them to users. It creates a convincing before-and-after demonstration.
Remember that the old and new systems may need to coexist and synchronize for some time. This requirement often appears unexpectedly.
13. The Enemy at the Gates
Your greatest enemy is time. Everyone else is an underestimated partner.
Remain open to criticism, new proposals, and small requirement changes. Every ignored comment can become a line in the indictment after a project fails. The earlier people challenge the solution, the better.
14. Make Compromises—Except on Quality
Compromise is permanent in project work. The one compromise you should not make is product quality.
When the team includes QA engineers, begin writing automated tests with the first lines of code and cover as much as reasonably possible.
15. Ban Premature Refactoring
From the first lines of code, a team may develop an irresistible desire to refactor and optimize the solution indefinitely.
Stop it. Experience shows that premature refactoring damages schedules and can even create new problems. Improve the solution when there is evidence that improvement is needed—not simply because improvement feels intellectually satisfying.
16. Surround Yourself with Allies
Give authorship to users, business stakeholders, and other participants. Once people see the system as their own creation rather than yours, the work moves much faster. You are no longer surrounded merely by participants; you are surrounded by allies.
Give up the claim to authorship and you may receive the credit anyway. The one who loses wins.
17. Data Storage Is the Real Problem
I often say that system design is simple until you have to manage data. Data management is expensive and labor-intensive.
Design storage as early and as carefully as possible, involving specialists from the start. Changes in this area are among the most expensive changes a project can face.
Actually, they are the most expensive.
18. Bureaucracy Can Be Your Friend
Documentation is tedious, but do not neglect it. Ask what would happen if half the project team resigned, burned out, became ill, or moved to another initiative. The effort required for a new person to enter the project should be minimal.
When nobody has time to write documentation, record meetings and demonstrations. If you cannot take a holiday during the project, you have become a tower of knowledge, and that tower must be dismantled as quickly as possible.
Share problems and failures early. You are not alone.
19. One Person Is Not a Team
Ask for help and delegate both individual tasks and entire areas of work. Responsibility can be shared with business functions, other project managers, analysts, or senior developers.
A team is formed by giving participants both authority and obligations toward the project. Without that, you risk creating a crowd of spectators watching one heroic gladiator fight lions and bugs alone.
Great responsibility creates great power. Do not reverse the phrase.
20. You Have Not Seen Real Problems Yet
Project problems grow like mushrooms. They can be prioritized, managed, transferred, or—when necessary—absorbed by moving the schedule slightly.
The real trouble begins when the first user enters the system. Existing project issues are suddenly joined by support, service stability, and availability. You must work with real user data and migrate it safely when the system changes. Customer requirements are added to business requirements.
The best strategy is a limited pilot launch—a canary release or beta test—and a gradual expansion of the audience until the system reaches 100% of its users.
21. Operations and End Users Are Your Ace
It sounds absurd, but project managers constrained by deadlines, requirements, and budgets often forget the people who will actually operate and use the system.
That is a serious mistake. End users can reveal additional scenarios and requirements that the business missed, and they can also stop an implementation entirely.
Their support becomes especially valuable when a customer is inclined to reject a project. Such a customer may ask users for negative arguments, but positive informal feedback changes the situation. The customer is no longer opposing IT or a particular project manager; they are opposing the expected effect for the company and, ultimately, their own interests.
The secret is simple: work closely with operations and end users.
Instead of a Conclusion
A strong team of motivated people can rescue even a project that appears hopeless. The reverse is also true: a team of highly skilled but unmotivated professionals can drive a project into the ground.
With the right motivation, synergy spreads through the project and creates a tailwind. That may sound decorative, but in practice it is even better.
One condition creates real synergy between business and IT: every participant must have obligations to the project. Obligations are not optional. Without them, the game is being played toward one goal and the final score is already printed on the board.
Surprisingly, synergy is created not by rights but by responsibilities.