Seven Rules for the Perfect Project

Humankind’s history is also a history of its projects, the successful as well as the unsuccessful. One of the historical projects that we today admire as one of the wonders of the world is the Pyramids at Giza. The Bible’s tower of Babel provides us with an illustration of what happens when a project goes wrong. Many (IT) projects today are implemented in a cacophony of confused voices and opinions, badly coordinated processes and unsuitable choices of technology. The following seven ground rules can help SMBs to implement IT projects efficiently and successfully.

1. Define the project requirements and goals as precisely as possible

Many projects founder because they lack clearly defined requirements and goals. Business management benefits should always be the main focus of IT projects. Project goals must be clearly defined and communicated. For example, a goal in introducing SAP Business One might be “Using SAP Business One we want to reduce IT costs by 50 percent within a year.” The foundations for a successful project are laid at the start. Consequently, before the project is kicked off, important questions to consider are: Who is taking part in the project, who is the project manager, what staff are involved? When does the project start and by when should it be finished? What will this project change in the enterprise, and how must this change be managed? These questions should be clarified in advance by a core team that includes project participants and the project customer (management, board).

2. Draw up a schedule and budget

Numerous studies concur that project schedules are often not kept to and budgets spiral out of control. The golden rule when scheduling is to always allow a sufficient time buffer for unexpected factors, or in case installing the software and putting it into operation takes longer than foreseen. This is particularly important in projects that last for several months. Businesses should always aim to be more conservative than optimistic when drawing up schedules. Staff who will later work with a new system must be given enough time for training, since whether or not they accept the system will determine the success of this system when introduced. In addition, project costs must be continuously monitored. This increases transparency and guards against the possibility of unpleasant surprises at the end of the project.

3. Assemble the right project team

This is a delicate task, since in every project team the whole is more than the sum of its parts. Similar to team sports like football or handball, assembling the right project team is a decisive factor in success or failure. Roles must be clearly allocated and the team must consist of a healthy mix of managers and staff qualified for the project. A project team consisting only of managers is as likely to fail as a team made up of staff members who, while suitably qualified, do not have any management experience. In addition, the interaction of individual players must be defined in the project’s roles and responsibilities, at the same time avoiding too much of a hierarchy. This can inhibit open discussion and cause personal and professional conflicts between team members to escalate. The project manager and project staff should undergo continuous training during the project. After completing a successful project, members of a project team deserve some recognition, be it in the form of a bonus, a pay rise or a promotion. This maintains motivation for the next project.

4. Always perform a risk analysis

The goal of a risk analysis is to gain more transparency at decision points and analyze possible “worst case scenarios” in advance in order to formulate countermeasures. Projects run with the slogan “no risk no fun” invariably fail. However, even well-planned projects encounter a number of critical junctures. Typical project risks include important staff members falling ill during a project, failure to meet agreed deadlines and conflicts of responsibility and friction within the team. A distinction must be made between what are known as project risks, arising from the project itself, and product risks, such as defective software. According to DIN 69905 the risk analysis is simply the “part of the project analysis that deals with project risk.” This prim definition fails to mention that risk analysis should take place as early as possible, ideally before the project starts. In this way factors that could jeopardize the project can be evaluated and corresponding countermeasures can be prepared. This is especially important in long-term projects, since project goals often change as a result of strategic management decisions. A project team usually has no influence on these decisions, which are generally unexpected, so these eventualities must be considered in the risk analysis.

5. Manage and monitor your project at every stage

“As soon as a project exceeds a certain level of time, budget or complexity, it must be managed and monitored using suitable methods. This requires a form suited to the team, the corporate culture and the project,” writes Dr. Nicolaus Wolff of cimt ag in a specialist article. Examples of this include project management tools such as SAP PS (Project System). IT projects are well-known for taking longer and costing more than was originally estimated. Effective project management enables (relatively) stress-free implementation and a good outcome. Continuously comparing target and actual data by comparing the project plan with reality, i.e. with the individual processes, is an important aspect of managing a project. This enables the actual course of the project to be brought back into line with the original planning in the event of deviations. It is also important to determine the impact of the current situation on subsequent stages of the project. This requires not only extensive communication between all participants, but also a continuously updated project plan that records to what extent tasks have been completed and what milestones have been reached.
The plan must also be kept up-to-date as regards duration, resources and individual concrete goals. It is important too to document in writing any changes in goals, duration etc. that arise during the project. “Verbal” project work leads to confusion, since in the end nobody knows exactly what should be done and what not. Apart from tools, active, effective project management above all requires a pronounced information, communication, coordination, management and team culture. If this is lacking, projects have slim prospects of success.

6. Document project meetings

Minutes do not just document decisions taken in individual meetings, they also form an important body of information on the project’s progress and the general project context. Minutes are often written after project meetings out of sheer habit. It has always been done, and is part of the ritual. Minutes are poured into the mold of a minutes record sheet following formula X, and sent out to the usual suspects in the distribution list. So far so bad, since most recipients put the minutes aside unread. Meetings are however important elements of project work, and this makes recording them important. Minutes must be written as objective reports that are correct in respect of content and unambiguous in their statements. They put the results of meetings, conversations, conferences and other events on record. As such they must faithfully reproduce what has occurred at the event. Minutes are a memory aid for participants at an event and also protect the project manager from needless discussions of the type “But that’s not what we decided”. Minutes are sent or distributed to all team members, regardless of whether or not they were present, and also where appropriate to the manager who ordered the project.

7. All’s well that ends well

Every project ends with a general evaluation or debriefing. The project is completed and initial practical experience of the new software is available. Now, at the latest, is the time for a retrospective. It should determine what went wrong, what goals were achieved, what went better than expected and what went worse than expected. A retrospective should never result in self-adulation by project participants or the project manager, but should lead to a critical examination of the entire project’s course – which may lead to a mainly positive assessment. Looking forward, questions such as the following should be clarified:

  • What can be learnt from the project for the future?
  • What concrete actions must be taken to stop mistakes being repeated?

The answers to these questions provide valuable insights for future IT activities. At the conclusion of a project it is also appropriate to thank all those who took part in it and, depending on the size and scale of the project, hold a celebration of the project’s conclusion, since recognition of the “human factor” is a crucial factor in the success of future projects. After all, who wouldn’t rather be praised than blamed!

Dr. Andreas Schaffry
Dr. Andreas Schaffry