Project Management In E-world

PROJECT MANAGEMENT IN e-WORLD Valentin P. Măzăreanu

Abstract When we speak about project management we understand that it means we are dealing with a complex activity which involves, among others, a strong relationship between members of the project team in terms of project information sharing or applying some complex project management models in our project plan. All these arguments, but not exclusively, justify the use of the specialized tools that can assist the project management activities. The implication of these, have the goal to support the project management process in all the related fields, like project risk management, project human resource management, project quality management and so on. Key words: project management, new economy, e-world Introduction We live in such days that the presence of a computer is all around us, gaining a place in all the human activities and making our work more effectiveness and perhaps more enjoyable. In these conditions, the project management couldn’t have just staid outside this trend. Actually, it is hardly acceptable in the 21st century that a project to be designed, implemented or managed manually1. Project management and project risk management are such activities that imply communications with a large amount of information or complex methodology and roadmaps. All these arguments justify the emergences of some specialized tools that can assist and support the project management and risk management activities. Such tools are: - groupware technologies (discussions data bases, schedules, management of documents, etc) - intranet/internet technologies and web-enabled information presentation - project management with the support of a software application - software tools for project risk management As the title is saying, this paper will try to deal with projects from e-world, also known as e-projects. So, a short presentation of the differences between traditional projects and e-projects would be appropriated2: Table 1 The differences between traditional software projects and e-projects drive a different approach for e-project management.

Requirement gathering Technical Specifications Project Duration Testing and QA Risk Management Half-life of Deliverables Release Process Post-Release Custom Feedback

Traditional Projects Rigorous Robust Measured in years Focused on achieving quality targets Explicit 18 months or longer Rigorous Require proactive effort

e-Projects Limited Descriptive overview Measured in days, weeks or months Focused on risk control Inherent 3 to 6 months or shorter Expedited Automatically obtained from user interaction

But even in this world of “e-” there are some “out-of-time” components, items that can affect the implementing and the management of any system, anytime. Next, there are some of these components, a list of Top 10 mistakes to avoid in implementing ERP systems3: 

Ph.D. student, Department of Business Information Systems, Faculty of Economics and Business Administration, „Al. I. Cuza” University“ of Iaşi, Blvd. Carol I, No.11, 700506, Romania, [email protected] 1 Oprea, Dumitru, Managementul Proiectelor. Teorie şi cazuri practice, Ed. Sedcom Libris, Iaşi, 2001, p.180 2 Kulik, Peter, Samuelsen, Robert, e-Project Management for the New Reality, at http://www.accelaresearch.com

10. Believing the journey is complete at "go live." 9. Not planning for - and minimizing - the interim performance dip after start up. 8. Failing to balance the needs and power of integration with seeking quick business hits. 7. Starting too late to address all things data (architecture, standards, management, cleansing, and so on) 6. Failing to staff the team with "A" players from business and technical sides of the organization, including program management. 5. Starting without an effective and dedicated senior governance council, including a single executive sponsor. 4. Selecting a strong systems integrator and then not heeding its advice. 3. Trying to create a solution incompatible with the company's culture. 2. Treating this as a technical project vs. a change that balances people, process, and technology; not using the power of the new, integrated information. 1. Embarking on the journey without a solid, approved business case, including mechanisms to update the business case continuously and to ensure the savings are baked into operational budgets. In Paul Dorsey’s opinion the elements of such a top 10 are4: 1. Don’t use a specific methodology because coding is all that is really important. 2. Create the project plan by working backwards from a drop-dead system completion date. 3. Don’t bother with a data model. Just build whatever tables you need. 4. Use a Technical Lead that has never built a similar system. Hiring such talent is too expensive. 5. Hire forty developers to make the coding go faster. (More is not always better). 6. Build the system in Java, even though most of the development team still thinks that Java is coffee and you have no intention of ever deploying to the Web. (“The right tool for the right job.”) 7. Three months before the system goes live, assign one junior developer to handle the data migration. 8. Skip the testing phase because the project is way behind schedule. 9. Change the system to support critical new requirements discovered during final development. 10. Buy a commercial, off-the-shelf package and customize it … a lot. There are many papers in this field, trying to identify the most comprehensive list of top ten mistakes, risks or uncertainties involved in a project. (Ex.: “The element of project risk management” from Net Com5, “Top ten mistakes and their mitigation steps” from Infosys6, “Software Project-survival guide” by Steve McConnell7). Other approaches in managing a project with success are those using a specific methodology. A methodology is a roadmap to an implementation. The purpose of a methodology is to deliver an implementation on time, according to specifications and within budget. Such a methodology is ASAP (Accelerated SAP), a detailed project plan by SAP that describes all activities in an implementation. It includes the entire technical area to support technical project management and address things like interfaces, data conversions and authorizations earlier than in most traditional implementations. The ASAP Roadmap consists of five phases8: Phase 1 - Project Preparation: Proper planning and organizational readiness assessment are essential which entails a determination of the following:  Full agreement that all company decision makers are behind the project;  Clear project objectives;  An efficient decision-making process; and  A company culture that is willing to accept change. Phase 2 - Business Blueprint: The “Engineer” delivers a complete toolkit of predefined business processes. During the Business Blueprint phase R/3's broad scope is narrowed to fit the industry-specific processes. Using questionnaires and the models from the “Business Engineer,” the business processes are documented to reflect the future vision of the business. Industry templates further accelerate the process by predefining industry best business practices. The result is a comprehensive blueprint of the business. During this phase training begins on R/3's integrated business systems. Level 2 hands-on training provides a step-by-step 3

Weightman, Clive, Top 10 ERP mistakes, at http://www.intelligententerprise.com Dorsey, Paul, Primele 10 motive din cauza cărora eşuează proiectele de Sisteme Informatice, at http://www.computerworld.ro 5 The Elements of Project Risk Management, at Net Com, http://www.netcomuk.co.uk/~rtusler/index.htm 6 Jalote, Pankaj, Software Project Management in Practice, Addison-Wesley, 2002, p.102 7 McConnell, Steve, Software Project-survival guide, Microsoft Press 1998, p.96 8 Bruges, Paul, ERP Implementation Methodologies, MSIS 488 - Fall,2002, at http://www.sap.com/index.epx 4

education of R/3 business process skills. The “Business Blueprint” is a visual model of your business' future state. It will allow the project team to clearly define the scope, and only focus on the R/3 processes needed to run the business. Phase 3 - Realization: Based on the “Business Blueprint,” a two-step process is begun of configuring the R/3 system. First the baseline system will be configured. Second the system is fine tuned to meet all of the business process requirements. Because the initial configuration is based on the blueprint, the baseline system gives a real-world view of how the business transactions will actually run. Phase 4 - Final Preparation: In this phase, the R/3 system is fine-tuned. Necessary adjustments are made in order to prepare the system and the business for production start-up. Final system tests are conducted and end-user training is completed. Initial audit procedures are developed. Phase 5 - Go Live and Support: In this phase, procedures and measurements are developed to review the benefits of the R/3 investment on an ongoing basis. SAP support and services are provided to ensure that the system continues to run smoothly. The Online Service System (OSS) provides electronic support using a remote connection. The “Implementation Assistant” provides answers for most questions that may arise. it is an easy-to-use repository of information defining what to do, who should do it, and how long it should take. The Ernst&Young LLP is proposing The Total Solution approach. This approach has five components9: Phase 1 - The Value Proposition: Building the business case. The key before any process can begin is to make sure it makes sound business sense. The following questions should be answered before the process is started:  Is the technology investment justified?  Does it match the company's objectives?  Does management understand what change means, and does that change have full support?  What is the framework for making decisions?  What milestones will measure the project's progress?  Is value being delivered throughout the process? Phase 2 - Reality Check: Assessing an organization's readiness for change. Since many people oppose change: it is something that needs to be anticipated. Status quo is easy; change is not. Therefore, the following questions need to be asked:  Is the organization ready for change?  Are there any hidden agendas? If so, how will they be managed?  Is everybody on board with the nature, scope, and pace of the change?  What are management's expectations? How those questions are answered will adjust the implementation approach. Knowing the answers upfront helps to avoid a possibility that the change does not match the client's reality. Phase 3 - Aligned Approach: Setting expectations. Delivering short-term and long-term value. Short-term as well as long-term benefits are key to any project's success. Even if change is uncomfortable for some, it is easier to accept if progress is visible. In this approach, the following tasks are performed:  Evaluate alternatives to a comprehensive reengineering project;  Craft a "best-fit" approach that allows the implementation to proceed in well-defined modules;  Communicate expected results to management. Keep communicating throughout the project so no surprises surface at the end. This approach helps keep the entire project on time, on budget and on management's agenda for success. Phase 4 - Success Dimension: The right blend of people, skills, methods, and management is important to the project’s success. The implementation team should include people with skills in process management, change management, knowledge management, and industry skills. Teamwork is very important. Phase 5 - Delivering Value: Measuring results and celebrating success. A project that does not show measurable results throughout the process is going to flounder. People will lose enthusiasm and the expectations of a new way of doing business become just another broken promise. It would be wise to make sure that every project pays continuous "value dividends" all along the way to minimize the risk of change. Other methodologies are: The Fast Track Workplan from Deloitte & Touche, methodologies based on Delphi method or the theory of utility, methodologies based on sensitiveness analyses or on historical observation and methodologies based on mathematical method like, Value at Risk (VaR) or various indicators (Probability of Default, Loss Given Default, Exposure at Default etc.)

9

Ibidem

As we were saying at the beginning of this paper, there a many software solution helping project managers in their work. We can mention: Microsoft Project from Microsoft, Artemis from Artemis International, CA-SuperProject from CA Computer Associates, Primavera Project Planner from Primavera, Openplan from Welcom, OPX2 from Planisware, Results Management 5 from ABTCORP.com, Time Line from TLsolutions, and others. According to „Project Management for Business and Technology” the most important benefits that such a solution can provide are10: speed of work, capabilities, effectiveness, economy, accuracy of data, and ability of working with complex data. From another point of view, among the benefits brought by project management software can be specified11 budget calculation, cost control, scheduling capabilities, communication through e-mail, exhibits, data import and export, capacity of working with multiple projects and subprojects, reports, resource management, planning, project monitoring and control, security, data sorting and filtering, “what-if” analysis. From these, the great benefit is provided by speed of work: once the data are collected and filled into the system, any operations (budget sheets, schedules, plans etc) can be done in minutes. And with intranet/internet technologies all these can be done from outside the decisional office. Another major benefit is economy: in most of the cases the computer is providing important advantages in terms of cost comparing with the manual system. Supposing that the data were filled in correctly, the possibility to make mistakes in processing them are reduced to minimum and updating them can be done with low cost. There are also software solutions for project risk management: RiskID Pro from Accela Research – a tool for identifying and evaluating risks in IT projects, RiskRadar from Integrated Computer Engineering Directorate, American Systems Corporation, a tool used in quantification, categorization, prioritization, tracking, controlling and managing risks, Cobra (Consultative, Objective and Bi-functional Risk Analysis) from C&A Systems Security, tool for cost management, budget analysis and what if analysis. Such a tool is @RISK for Project from Palisade Corporation, which uses a technique called “simulation” to combine all the uncertainties identified in a project. In is just as running hundred of “what if” scenarios all at once. @RISK allows defining uncertain values in Project as probability functions using standard @RISK distribution functions. In @RISK, uncertain variables are entered as probability distribution function. For example: - Start = RiskTRIANG(28.07.04, 03.08.04, 05.08.04) o It takes into consideration that an activity might start in one of the days mentioned (28.07.04 – first value, 03.08.04 – most probably, 05.08.04 – the higher value that activity can take) - Duration=RiskNORMAL(4, 5) o It takes into consideration that the duration of an normal activity is four units (hours, days, etc as specified in project), but could have a standard deviation of 5 units - Duration=RiskTRIANG(2, 3, 5) o It takes into consideration how long can be an activity, in terms of units (hours, days, etc) where 3 is the most probably value Risk Analysis in @RISK is a quantitative method that seeks to determine the outcomes of a decision situation as a probability distribution. In general, the techniques in a @RISK Risk Analysis follow four steps12: 1. Developing a model – by defining the problem or situation in project format 2. Identifying uncertainty – in entries in the project and specifying their possible values with probability distributions, and identifying the uncertain project results that you want analyzed 3. Analyzing the model with simulation – to determine the range and probabilities of all possible outcomes for the results of your project 4. Making a decision – based on the results provided and personal preferences In next two diagrams I will exemplify the results of a @Risk simulation in a project about a software solution implementation. The implementation should start at 02.08.2004 and end at 13.12.2004. But 10

Nicholas, John, M., Project Management for Business and Technology – principles and practice, second edition, Prentice-Hall, Inc., 2001, pp.385-386 11 Opran, Constantin, Abaza, Bogdan, Microsoft Project – suport de curs, Masterat în Management Proiecte Internaţionale, Facultatea „David Ogilvy” 12 @Risk for Project (guide to) - Advanced Risk Analysis for Project Management, Palisade Corporation, 2000, p.25

according to the uncertainties I have used, for the date of 13.12.2004 the success of this implementation is somewhere around 15%. This project will be implemented with 100% success most probably by 21.12.2004.

Fig.1 The Diagram for the final result of the project (@RISK format)

Realizarea transferului de cunostinte/invatarea din greseli/Duration (Dist.12)/ Determ inarea strategiei finale de desfasurare/Duration (Dist.11)/

0.2212847 0.2101224 0.1531201 0.1044836

Determ inarea scopului proiectului/Start (Dist.1)/ Redactarea specificatiilor prelim inare/Duration (Dist.3)/ Dezvoltarea codului sursa/Start (Dist.5)/

Analiza nevoilor/Duration (Dist.2)/ 0

0.2876234

Revizuirea codului m odular/Duration (Dist.6)/

0.409707 0.4014402 0.3730498

Testarea integrarii m odulelor/Duration (Dist.7)/

0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45

Fig.2 The Diagram for the final result of the project (Excel format)

Conclusions In this paper, beside the presentation of some technical aspects, I have tried to present the point of view of some specialist in project management and some of the best practices in this field from different companies. We have seen that also in this field of project management the software products gain more and more terrain. We have to be carefully not to step on the “other side of the balance” and to fail in project implementation due to too much trust in these solutions. At the end we can cite Clive Weightman: “Of course, a "cookbook" doesn't exist that produces a perfect project every time. Still, ignoring the advice of veterans almost certainly will trigger failure.” References 1. ***, @Risk for Project (guide to) - Advanced Risk Analysis for Project Management, Palisade Corporation, 2000 2. Bruges, Paul, ERP Implementation Methodologies, MSIS 488 - Fall,2002, www.sap.com/index.epx 3. Dorsey, Paul, Primele 10 motive din cauza cărora eşuează proiectele de Sisteme Informatice, at www.computerworld.ro 4. Jalote, Pankaj, Software Project Management in Practice, Addison-Wesley, 2002 5. Kulik, Peter, Samuelsen, Robert, e-Project Management for the New Reality, at www.accelaresearch.com 6. McConnell, Steve - Software Project-survival guide, Microsoft Press 1998 7. Nicholas, John, M., Project Management for Business and Technology – principles and practice, second edition, Prentice-Hall, Inc., 2001 8. Opran, Constantin, Abaza, Bogdan, Microsoft Project – suport de curs, Masterat în Management Proiecte Internaţionale, Facultatea „David Ogilvy” 9. Oprea, Dumitru, Managementul Proiectelor. Teorie şi cazuri practice, Ed. Sedcom Libris, Iaşi, 2001 10. The Elements of Project Risk Management, at www.netcomuk.co.uk/~rtusler/index.htm 11. Weightman, Clive, Top 10 ERP mistakes, at www.intelligententerprise.com Aparut in Măzăreanu, V., Project Management In e-World, The Proceedings of the International Symposium „Innovative Applications of Information Technologies in Business and Management”, 14-15 Octombrie, Iaşi, ISBN 973-716-189-0