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.

Traditional Projects e-Projects

Requirement gathering
Technical Specifications
Project Duration
Testing and QA
Risk Management
Half-life of Deliverables
Release Process
Post-Release Custom
Feedback
Rigorous Limited
Robust Descriptive overview
Measured in years Measured in days, weeks or months
Focused on achieving quality targets Focused on risk control
Explicit Inherent
18 months or longer 3 to 6 months or shorter
Rigorous Expedited
Require proactive effort 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, vali.mazareanu@feaa.uaic.ro
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
4
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
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)
0.409707

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

0.4014402

Realizarea transferului de cunostinte/invatarea

din greseli/Duration (Dist.12)/
0.3730498

Determ inarea strategiei finale de

desfasurare/Duration (Dist.11)/
0.2876234

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

0.2212847

Determ inarea scopului proiectului/Start (Dist.1)/

0.2101224

Redactarea specificatiilor prelim inare/Duration

(Dist.3)/
0.1531201

Dezvoltarea codului sursa/Start (Dist.5)/

0.1044836

Analiza nevoilor/Duration (Dist.2)/

0 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