beteo ALM Experts Blog

Category: Project Management

  • Proof of Concept – Less Risk for System Implementations

    Scoping for defined requirements and harmonized expectations
    The scoping approach allows you to define requirements, expectations and project scopes when systems, methods and processes are implemented. This results in aligned expectations, a well-designed system architecture, defined requirements as well as a structured implementation roadmap. If the roadmap is implemented in several iterations, quick wins are achieved in addition to a direct benefit to the project client and the users.

    Technically complex problems as a challenge
    If system implementations are planned in technically complex environments, in addition to the purely technical requirements that have to be met, the following questions should be addressed:

    • Is a clean system installation possible?
    • Can the solution be integrated into the existing system landscape?
    • Which is the best way to coordinate the installation and integration with the IT organization
    • Are all used technologies compatible?
    • Which interfaces are affected, and in which way?
    • Can the described functions really be implemented?
    • How does the system behave with regard to usability?
    • Will the system be accepted by the users?
    • Which are the actual costs to be faced?
    • Which technical capabilities and roles are required for the implementation?
    • Can the planned benefit really be achieved?
    • How about the capabilities of partners, manufacturers and providers, and what characterizes collaboration with them?

    The above questions are only part of the criteria which are relevant to success. To answer them, further activities are necessary. Very often, there is a great deal of uncertainty about the technical and organizational feasability of the project as well as about the time and costs involved.

    Proof of concept: minimization of risk in decision-making process
    In the context of system implementations, proof of concept (POC) equals a technical feasability study. POC can be used as a part of scoping to check for technical and organizational feasability of projects. Prior to execution, the criteria relevant to success and the subsequent steps must be clearly defined in order to ensure maximum benefit. For working out a POC, it is recommendable to implement a mock-up or a prototype comprising the core functionality. This allows to test the functions, define them accurately and involve the users in the planned project at an early stage. Proof of concept reveals which requirements can be met in which way and which functionality demand workarounds or additional solutions. Thus, time and cost expenditure for installation and integration into the existing system landscape can later be well estimated and planned in agreement with the responsible IT organization.

    Pilot pojects as a performance indicator
    Experience has shown that working with pilot projects significantly adds to success. The prototype is used in productive systems on a limited scale. There are various alternatives to proceed:

    • limited user group
    • limited functionality
    • limited process scope
    • limited and/or isolated system environment

    Working with a pilot project allows you to rather accurately pre-estimate if the system in action meets all requirements, covers the planned functionality and proves to provide the expected benefit.

    Summary

    Proof of concept allows you to find out if the implementation of a system can be technically realized, and to evaluate the capabilities of manufacturers, partners and providers as well as the quality of collaboration with them. In addition, the expected time and cost expenditure for installation and integration into the existing system landscape are made calculable and can be planned in accordance with the responsible IT organization. Prior to execution, the criteria relevant to success and the subsequent steps must be defined.

    It is recommended to create a prototype which includes the core functionality, i.e. those functions from which the greatest benefit is derived. This allows the users to be involved at an early stage of the project; as a positive result, user-friendliness and acceptance by users can be evaluated and taken into account. If the prototype is tested in the context of a pilot project with either a limited user group, limited functionality, limited process scope, or on a separate system, this will result in a realistic view of the potential of benefit. Proof of concept is used to work out facts and foundations in order to minimize the risk of making inappropriate decisions in the process of system deployment.

  • Only Motivated Users Make IT Projects Successful

    The introduction of a new IT solution entails a large deal of different changes. New roles and responsibilities must be defined, supported by additional new software. An early integration of the future users is of great importance, but very often, there is not enough attention paid to it.

    A typical example from a “normal” project: Shortly before the new solution goes live, there is – in most cases – still one pending issue on the to-do-list of the project which has already been postponed several times: the user training. The budget, including several amendments, is already stressed at that time, and the last days before going live are busy with remedial actions.

    Neither client nor project manager and project team have so far attached value to the training of the users, although insufficient training of future users can easily turn into an unexpected obstacle in the project workflow.

    The results are as follows:

    • Instead of a user training, the project team is pursuing “a learning on the job” strategy
    • The users are forced to use the new system without or with insufficient training.
    • The project team supports the users after project finish, so that there are no resources for new projects left.
    • As applying the software is a gradual process, nobody really knows the exact time when change management starts to have an effect.

    The enormous damage for the enterprise is obvious:

    • There are additional expenses, meaning real costs, by the parallel use of the old and the new solution, which involves additional work for coordination and mutual arrangements.
    • The absence of a user training and the delayed transfer of know-how result in further costs, since the new solution cannot be used as scheduled. The planned benefit fails to arise.
    • The users are frustrated and do not come to terms with the new tool. There is an atmosphere of discontent, and the new system runs the risk of not being accepted.

    This suggests the conclusion that the planning and realizing of user trainings ranks among the most important success factors for the introduction of a new system. Also with respect to the implementation of an internal “support structure” and “support culture”, considering the aspect of knowledge transfer from the project team to those who use the solution is imperative.

    This means that the issue of user training must be communicated in the project team at an early stage and be actively promoted. This results in users who are fit for using the new tool when it is going live.

    This target can be achieved by the following measures:

    • From the very beginning, one of the users participates in the project meetings as user representative. He will get familiar with the introduction of the new tool and assume responsibility for the planning and realization of the training. This enables him to have a say in the development of the tool from a user´s perspective and to co-determine the structure and the procedural methods of the training.
    • Fixed dates as those for software updates or data migration, as well as downtimes caused by technical failure and holidays, must be observed when planning the training. Training sessions take place only if all training participants have time not only for taking part in the training, but also for familiarizing themselves with the new solution afterwards.
    • A concept to support the users is figured out: Who is in charge of answering general user questions concerning the application? Who will help the user with the practical use of the solution?
    • The individual roles such as key users, administrators, first and second level support, as well as persons responsible for operation or test execution are clearly defined. The employees assume these roles at an early stage of the project and are trained respectively.
    • The users are informed in time about the introduction of the new software and the training involved with it. An effectively flowing communication within the project, usually referred to as project marketing, is actively supported by all participants and responsible persons.
    • All relevant requirements for a successful training are planned in time, and meeting these requirements is secured by the time the training starts.
    • The training classroom is booked (and well aired :-))
    • The training documents are printed
    • The computers are set up and started, the software is installed
    • The system is ready to get started, training documents are handed ou
    • The users are not disturbed during training times
    • There are breaks for the participants to exchange experiences
    • A printer is available to allow the participants to make screen-shots
    • The trainer is well prepared
    • Feedback by the participants allows for the training to be improved and optimized in future
    • Immediately after the training, the users should be able to use the new solution. The direct transition is important to take advantage of the positive momentum gained from the training. Now the systems along with an uncomplicated support environment must be available.

    Summary
    For the successful introduction of a new software solution, not only the technical requirements must be fulfilled. In addition to consistency, availability and user-friendliness of the solution, it is important that the users are well-informed, personally engaged, highly motivated and well trained. The users should be involved in the project at an early stage of the project, the training must be planned in time, including the means required, and carried out in a professional way. Least not last, the new software must be made available right after the training and be used. The option to use the old system must be abandoned. If these clear principles are observed, the successful application of the new solution – and thus the success of the project – will be secured.

  • SAP xRPM and HP PPM – Complementary Solutions?

    Whether in Gartner’s Magic Quadrant for PPM or in evaluations for project portfolio management tools, HP PPM (HP Project and Portfolio Mangement Center) and SAP xRPM (xAPP Resource and Portfolio Management) are always positioned as competitors. But do the specific features of these very specialized solutions justify this positioning?

    What are HP PPM and SAP xRPM ideally used for?
    HP PPM has more or less been exclusively designed to be used for managing IT project portfolios. When it comes to integration with software development and application lifecycle components like testing, configuration management databases (CMDB), and business process management tools (BPM), HP PPM shows its real strengths. The strong process engine of HP PPM cannot only control and drive organizational process, it can also control the technical execution of other software components and allows the integration of quality assurance measures and impact analysis steps. Traditional workflow tools rarely go beyond automating organizational flows. With HP PPM, it is possible to systematically control and track portfolio authorization and to include decision criteria from integrated application portfolio analysis. The following also need to be understood and fed back into the decision process: the impact of a project to the IT system, whether or not implementation of the existing system increases the complexity of an IT system, and if the complexity makes it impossible to make a change to the system. What is missing in HP PPM, are capabilities to thoroughly analyze a project portfolio financially.

    SAP xRPM has been built to support business project portfolio analysis with financial data – not for only IT projects, but for projects of any kind. Based on information from SAP BI (SAP Business Intelligence) and SAP SEM (SAP Strategic Enterprise Management), this is readily identifiable by its architecture. The tool’s integration with SAP financial business data is SAP xRPM’s greatest advantage. SAP xRPM can access the most recent financial information from the customer’s SAP system anytime. Additionally, SAP SEM allows defining and running ad hoc financial simulations, and a “What-if analysis” can be run as part of a portfolio assessment. As opposed to HP PPM, SAP xRPM shows weaknesses in process control and in the area of specific IT portfolio analysis needs. In this area, the integration with development and application lifecycle technology is missing.

    Conclusion
    The decision for the right portfolio and project management solution normally depends on its integration with the management information and tools of the project resources. Missing integration means additional effort and challenges for the planning and execution. HP PPM and SAP xRPM deliver unique integration but into two very different areas: application portfolio versus financial information. The article “PPM – Alibi without Impact Analysis” provides further information on which functions should be covered by a portfolio and project management solution, and how different vendors with their products differentiate themselves.

    The logical consequence from the above positioning could be a complementary use of both HP PPM and SAP xRPM. This way, portfolio management can profit from the strong process engine of HP PPM and the analytical capabilities of xRPM. From a technological point of view, the two solutions can ideally marry, and HP PPM provides the technological capabilities to do so. It can also integrate a lifecycle product like SAP xRPM Architecture, concepts and target use of the tools are different. For this reason, the key to a successful project portfolio management solution is to combine both tools and precisely define the requirements upfront. Only then can the combined HP PPM and SAP xRPM be designed, and failure can be prevented. HP PPM properly integrated with SAP xRPM can be PPM at its best!

  • HP PPM and MS Project – Synergy Potential with Challenges

    The upgrade from Mercury ITG 6.0 to HP PPM 7.0 entailed a much improved project management module. Project Management has been separated from the actual PPM workbench and is now available as a “zero client” over the web. The new Project Management Cockpit centrally integrates all project activities from modules like Portfolio Management and Resource Management. At a glance, the most important milestones, project status, project risks, scope changes, resource availability and issues show up. Project health or project controlling indicators like Schedule Performance Index (SPI) or Cost Performance Index (CPI) can be automatically calculated and graphically represented.

    Integration with Microsoft Project – both a blessing and a curse
    The bi-directional integration with MS Project is by far the most important step forward. This integration makes a lot of sense. HP PPM 7.0 promises similar functionality like MS Project for the management of project plans. This target is not really met by the current version though. On one side, important functions are missing, and despite very valuable cockpit views, navigating through project plans is too laborious. In addition, replacing Microsoft Project with HP PPM Project Management is difficult since MS Project, is successfully established in many places as the quasi standard to support project management. Enhancing Microsoft Project with HP PPM Project Management still corresponds to a real market need since users often see deficiencies in MS Project’s handling of resources and interdependencies in multi-project management.

    Conceptual Design – the Key to Success
    In order to optimally support project management, the proper design of the interaction between the use of HP PPM and MS Project is required for all available integration. It is of highest priority to define which function to perform in which tool and to what level activities such as phases, milestones, task groups or even tasks are planned where. With its strength in pulling together project data and in presenting management information, HP PPM lacks support for building and changing project plans. The reverse is true for MS Project. The right questions that need to be asked early on are the following:

    • Which system should have the lead?
    • Where are risks entered and maintained?
    • Where will resources be managed?
    • Where is progress tracked?
    • Which level of granularity tasks exchanged?
    • Which milestones are shown in the cockpit?
    • On which levels are resources allocated (for project phases, milestones, task groups or even tasks)?
    • On which of the above levels are work hours booked?
    • Where is the baseline of the project plan maintained?
    • Where are templates created and maintained?
       

    The same is valid for the actual project data.

    Once the integrated solution is designed, this combined system needs to be correctly customized; it is here where the devil lies in the details. When the exact impact of a setting is unknown, data exchange can easily adulterate reporting, and the integration of the tools produces chaos.

    Conclusion
    Many of HP PPM 7.0’s new Project Management features make sense and can produce great value for the customer. HP PPM’s strength for project management lies primarily in an aggregated management view and in the integration with other modules like Portfolio Management, Resource Management or Time Management, where MS Project is already the established operational project management tool in most of the companies. For this reason, a bi-directional integration corresponds to a market need and promises important benefits. But the building of such a combined project management solution is not trivial. An integrated use needs its own proper conceptual design and good experience for its implementation. Design and implementation need clear decisions on what functions are to be performed in which tool and on which granularity level activities (e.g. phases, milestones, task groups or tasks) are defined where. The impact of each setting and the interaction between the tools needs to be understood in detail. If these challenges are overcome, doors open for program and project management to profit from promising synergies of the combined Portfolio AND Project management solution.

  • beteo Miniguides – Project Collaboration

    Thanks for this comprehensive list and clarity on the PPM, PM, P±PM terminology.
    How do companies such as Clarizen fit in this categorization of yours? We consider ourselves more in line with being a Project Collaboration solution by focusing on team adoption and sharing via email integration and built in collaboration tools.
    Shall we introduce a new category ‘PCM’ – Project Collaboration Management?

    Through a comment from Clarizen’s Gil Heiman we came up with the idea of creating a beteo Miniguide with Project Collaboration tools. Every reader is invited to contribute to the quality and completeness of the list through comments or feedback.

Powered by