According to the latest report by the Project Management Institute (Pulse of Profession, February 2014), almost half (44%) of strategic initiatives undertaken by organizations is assessed as unsuccessful. The causes of difficulties in the implementation of projects include unclear goals and their relationship with the company strategy, insufficient management support, ambiguous priorities or conflicts related to the availability of key people. All of these elements require improvements that can be summed up in one word: preparation.
Already three centuries ago, Benjamin Franklin argued that by failing to prepare, you are preparing to fail. Therefore, a well-prepared project should begin long before the agreement is signed, a schedule is set up, and first works are commenced.
Why: goals and results
The first step in the project preparation should be to determine its goal and expected business results. The goal of the project should be realistic, measurable and consistent with the strategic objectives of the organization. It should also clearly explain why the company wants to engage its employees and financial resources to carry out the project. An example of the goal may be defined as follows: lowering maintenance costs by at least 5% compared to the state before implementation. A well-defined goal will in the future “lead" the project team, determining the directions of the work and facilitating decision-making.
The determination of expected results of the project requires deep reflection on the major problems faced by the organization, and the potential for development, as well as the evaluation of their actual impact on the business. Is the efficiency of logistics processes low due to a lack of additional control reports? One possible solution is a project for the development of these reports. Perhaps the real problem lies in too intricate and complex processes of purchasing and storage, which are conducive to mistakes and inconsistencies, and, therefore require simplification? Then it is necessary to prepare a business analysis project, which will result in organizational changes combined with changes in the management systems.
An evaluation of the importance of individual problems for business operations will also facilitate decision-making. A dozen or so days of work of the project team needed to design and deliver the strategy of approval may pay off within one month after the implementation as a result of a sealed purchasing process. The key success factor is to identify the major problems and potentials; otherwise you may find that the project does not solve the problems that have the greatest impact on the organization. Continuing the example provided above, we can conclude that the expected outcome of the project could be the implementation of organizational changes and the provision of a tool in SAP ERP that enables a dynamic diversification of business partners who handle service requests based on the analysis of estimated costs of processing a request.
When defining the goals and results of the project, it is easy to fall into the trap of sketchy statements (“performance improvement", “significant reduction of costs"), which look good in a presentation for the management board, but which will be difficult to rationally evaluate at the end of the implementation. Another potential pitfall is the expectation that the implementation of the management system will be sufficient to achieve the goals assumed. The omission of tasks related to organizational changes in these expectations significantly increases the risk of project failure.
How: the strategy
Business reasons for launching the project are known. Therefore, it is time to determine the strategy (rules governing the project work will be set out in the project methodology). The first step is to identify the priority of the project in the context of other initiatives conducted by the company (e.g. construction of a high-bay warehouse, implementation of SAP HCM). Placing the project on the map of all undertakings of the organization will facilitate the identification of risk factors and improve the decision making related to e.g. the availability of key personnel for each project (e.g. for a chief accountant, it is the most important to work in the HCM project due to the settlement of accounts with employees).
The company’s executives and leaders of the planned project now have time to reflect on the possible constraints related to the undertaking (e.g. transformation of ownership of the company, a planned promotion of the CFO, a necessity to shut down a production plant). In addition, it is possible to determine in advance the decision paths that streamline decision-making during the project.
It is also a good time to think about how organizational changes related to the implementation and changes in scope will be identified, managed and introduced. The management board may, for instance, appoint a dedicated manager for this area, who will oversee the organizational changes in all ongoing projects. The effectiveness of the solution can be further improved by setting a time frame for reporting and approving the changes so that they are incorporated in the project. Another important aspect is to establish the rules for managing risk factors before they are defined at the start of the project.
Finally, it is also an appropriate time to talk about the financing of the project (CAPEX/OPEX), sources of financing (e.g. a dedicated corporate budget or a budget of individual departments/companies) and the rules for estimating and monitoring of the project expenditure.
Who: the team
The next step is to determine all project stakeholders who – through active participation or as beneficiaries of the implemented solution – should be taken into account at the project planning stage. When identifying the stakeholders, it is also important to look beyond the organization and to take into account e.g. a potential implementation partner, cooperators, current providers of legacy solutions and other entities cooperating with the company or competing with it.
The first group that must be analyzed includes decision-makers (e.g. the management board, heads of business departments) and project manager. Even before we start a project, it is worth considering which of these persons should be members of the steering committee, either due to their position in the company (decision making), covering their area of responsibility with the implemented object (impact) or because of a constructive approach to solving difficult situations.
At the start of the project, the company’s management appoints project teams and designates leaders of individual functional and technical areas. To ensure that everyone is engaged in the project from the first day, it is recommended to identify the key members of the team well before it starts. You can also think about replacements in case of fortuitous events. The identification of team members well in advance gives you the opportunity to better assess their availability, competence and interpersonal skills relevant to the cooperation and achievement of assumed objectives.
Thinking about the team, you should consider establishing a relevant incentive system for its members (if a given organization does not have a ready-to-use model). The solution may depend on the specific nature of a particular project, such as the level of employee engagement in the project work, or it may be dependent on the achievement of the set objectives of the project. Whatever the final form, it is an important element stimulating the engagement in the project work, especially in difficult and challenging moments of the project.
You may not forget about users either. As the main beneficiaries of the developed solution, they will assess it, especially in the first months following the implementation. In addition, their proficiency in using the tools created will determine the efficiency and effectiveness of daily business operations. It is, therefore, recommended to provide in advance the proper communication to make sure that users will have a positive attitude towards the planned change in the first place, and secondly, to smoothly and with minimized concerns switch from the present state to the state after the implementation.
An implementation partner is another element of the teamwork puzzle. The selection of the company with which we will jointly carry out the project work is virtually a separate sub-project that should be covered in a separate article. What is worth considering is the understanding of the goals of the organization, the offered range of services (implementation services, an application service, additional services), reference projects implemented in each of the implemented areas, international experience, care for the development of consultants’ skills or adjustment of the organizational culture. It is recommended to verify the levels of cooperation with the system manufacturer, which will allow, for example, for purchasing licenses or obtaining a quick access to the manufacturer’s technical support desk.
Speaking about the technical support, it is worth conducting an inventory of currently used systems and establishing or confirming the scope of support for them. Some applications may be replaced by a new solution. Others will be used as a source or recipient of information from the new system. Therefore, it will be necessary to create interfaces. The implementation often puts manufacturers or caretakers of these systems in a privileged position. So it is better to make sure in advance that terms of cooperation are advantageous to avoid any unpleasant surprise during the project.
Finally, each organization operates within a particular ecosystem. Business partners (e.g. customers, suppliers, subcontractors), government authorities or regulators (e.g. tax office, social security institution, PFSA) will be at least indirectly affected by the effects of the implementation. When preparing the project, it is necessary to make sure that the appropriate stakeholders are informed about the implementation and the possible impact (or lack thereof) on their operational activities.
When: plan and schedule
From the point of view of the management board and project manager, a schedule of the project means tasks scheduled for execution at a specific time, confirmed by the achievement of defined milestones. During the project preparation, it is worth looking at the schedule from a slightly different perspective.
First of all, when setting up the time frame of the project, you should take into account the seasonality present in virtually every business. If important moments of the project (e.g. conceptual work, tests, training) are scheduled at the peak of production or sales, then with a probability bordering on certainty you can also schedule the postponement of the go live. Instead, it is recommended to make a creative use of these moments in the company’s operations for activities that do not require a huge involvement of business representatives (e.g. configuration and development work, preparation of training materials, unit/internal testing).
The second important dimension is a calendar applied to the project schedule. Typical periods of limited availability (public holidays, vacation periods, long weekends) even in the case of long projects can break down a precisely constructed schedule. So it is recommended to analyze in advance the time for which the project is planned, and adjust the schedule accordingly or … introduce a restrictive vacation policy for the members of the project and the Steering Committee. A special challenge awaits managers of international projects, in which it is necessary to synchronize the project schedule with the public holiday calendar in two, and often three or more countries of origin of the project participants.
Where: structure and location
An essential element of the project preparation is a verification of its organizational and geographical scope. Modern organizations are complex organisms: groups of companies, multi-division or multi-site companies, not to mention corporations operating internationally. The organizational structure and the geographical locations where work is to be done will directly affect the difficulty of implementation in terms of potential variants of business processes or the complexity of the preparation and provision of data for the target environment.
The organizational complexity also affects issues related to end-users: their number and individual experience. These elements will have a direct impact on the scope and scale of training, the scope of support during the project and after the go live. A remarkable challenge may be to develop an optimal model of support for users working in more than a dozen or several dozen locations all over Poland or worldwide.
The structure and location of the company will also determine the preferred location of the project work (availability of key personnel, easy access to the location, reduction of logistics costs). Therefore, it is recommended to think over the possibilities of communication between divisions (tele-and videoconferences) and the rules of remote work that will be used during the project.
What: the scope
Defining the scope of the implementation is in itself a difficult, time-consuming project that requires special attention. Often at this stage, the duality of implementation projects, balancing between the operating activities of the enterprise and IT, is revealed. In a typical scenario, the IT department, which is supervising or preparing documentation for the purposes of the purchasing department, expects the business to provide specific requirements regarding the implementation. A strict, formal list of requirements may, however, result in ambiguous or incorrectly interpreted requirements. In turn, business representatives perceive the project as a unique opportunity to implement the requirements, needs and nice-to-haves resulting in a wide functional range.
Implementation is a rare event and produces a natural desire to implement solutions for the future, without proper context and business purpose. As a result, the definition of the scope often boils down to the creation of a list of functional and non-functional requirements, and then, based on them, to the collection of information about the cost of their implementation from potential implementation partners.
A good preparation of the implementation scope is, however, the first moment that requires firm business decisions. It is at this stage that it is best to determine, which processes require system support or improvement so that the whole organization gains the most. When classifying the requirements, it is best to use the MoSCoW method described in the second edition of the Business Analysis Body of Knowledge.
- Must (critical/mandatory): requirements that must be met in order for a solution to be considered a success.
- Should (required): requirements with a high priority that should be present in a solution, if possible. These are often critical requirements that can be implemented in various ways (e.g. through an organizational change instead of a solution in the system).
- Could (optional/additional): requirements which are of a certain value to the organization but their delivery is not necessary to the success of the project. Their implementation very often depends on time and budget limitations.
- Won’t (rejected): requirements which are not included in the scope of the project. They may comprise functions that will be implemented as part of another project if they meet specific business requirements (e.g. launching a new product line).
This approach has several advantages. Firstly, even before the start of the project, you can deliberate without emotions associated with the project, which requirements must be fulfilled to achieve the business success of the project. Secondly, by assigning priorities to requirements you can better plan the financing of the project; for example, divide the budget among individual groups of requirements, taking into account the provision for new requirements that will naturally arise during the work. Thirdly, by already defining the validity of the requirements during the project work, project participants focus 100% of their attention on actual business needs, minimizing discussions about issues not critical to the business.
As a result, instead of engaging the team in designing dozens of reports that will be used once a year and reduce losses by several hundred zlotys, the project work can focus on functions that will bring a more measurable value, for example, the automation of communication with business partners, which will help reduce the workload of employees, save tens of thousands of zlotys and additionally, attract new customers.
The only, albeit potentially important difficulty that you should be prepared for, is an insufficient involvement of key decision-makers in the preparation of the project prior to its establishment. The absence of a formally defined project may be an argument in favor of postponing difficult decisions. In such situations, it is recommended to refer to the goals of the project and the financial aspects, which are a good “road map" to making such decisions.
When defining the scope of the planned project, it is difficult not to mention two important accelerators, which can significantly simplify and accelerate the project work. The first one is a list and description of business processes. Often companies already have such a material, for example, created for purposes of the implementation of a quality management system. It will provide an excellent basis for discussions at the concept stage. When preparing for the project, before choosing a system or an implementation partner, process owners may deliberate where the processes can be simplified, standardized (e.g. in a group of companies) or where the description of a process does not keep pace with reality. Of course, both the identification and the description of processes can also be made during the implementation, in the first step of the concept.
The second important accelerator is a carefully thought out strategy of master data management. Although they are a key element of the control of business processes, master data are often underestimated due to the stakeholders’ focus on the functional aspects of the solution. The availability, quality and process of master data management before and after the project belong, however, to key factors of the project success. That is why it is so important to establish rules and procedures for handling the master data, to designate persons responsible for the supervision over data or even to form a unit that will be responsible for this area in the organization.
What next?
A thorough and comprehensive preparation of the project is only the beginning of the road to a successful implementation. Now, the organization is aware of the challenges awaiting it, and equipped with the knowledge and tools to meet them. So there is nothing else to do, but to formally establish a project and start the project work in full readiness.