Project Management: A Key Element in Building Successful Information Systems

Katherine Duliba, PhD, Dulcian, Inc.
Craig Warman, Computer Resource Team, Inc.

 

Introduction

Project management is a key element in building successful information systems for a variety of reasons.  Project management can span activities ranging from contract negotiation, to plan administration, from solving interpersonal difficulties to calculating customer profitability.  All of these activities must be successful at some level in order for the entire project to be deemed a success.

This paper describes why project management is important, and includes several techniques for project planning, including writing detailed project plans and chairing status meetings. 

 

Motivation

One of the primary, driving factors behind active project management is that it takes fewer resources to proactively manage the project than not to manage the project.  This fact has been proven through first-hand personal experience.  In one particular instance, our computer consulting firm was involved in multiple projects.  One of these – a project that consumed a large number of resources –  proactively managed.  A second project occurring simultaneously was not proactively managed, because it was in the latter stages of system development.  The majority of the code (80%) had been written and was being tested.  In essence, an unofficial experiment had been undertaken.  For six months the first project and client were managed proactively.  The second client, by default, was managed reactively during the same time period.  Detailed project plans were written and updated for the first client, along with weekly status reports and status meetings.  The first project entailed a very demanding delivery schedule, but after we had met intermediate milestones, they became more confident in the relationship. 

 

During the same time period, for the second project, things would seem to be fine for one or two or three weeks.  Then, seemingly out of nowhere, the second client would perceive that a crisis situation existed.  For example, a certain report or application was now urgently needed, or the client would indicate that our developers had been unresponsive to their bug fix requests.  This “fire drill” required that the project manager, technical lead and business support personnel to strategize about how to respond.  Time-intensive discussions would be held, emails would be sent, and dealing with the situation expended nontrivial amounts of emotional energy.   Once a particular strategy and response had been devised, we would then get back to the client.  In analyzing the situations in retrospect, it seemed that the fire drills arose because developers were unresponsive to client’s casual requests, or because the client may have forgotten to schedule some piece of work.  Consequently, the client escalated the urgency of their request, from “casual” to “emergency.  This did result in action, as we responded to this emergency, but this was clearly not the most productive and efficient way to manage the project on a long-term basis.

 

In comparing the two projects over the last three months of this unplanned experiment, we found that managing the second project took as many hours a week as the first project, even though the first project was about three times larger.  Not only did it take the same amount of time, but responding to the fire drills was not a satisfying experience.  We concluded that it would take less time to proactively manage the second client than to do so reactively.  Even if a person does not explicitly manage a project or client, implicit management is still taking place. 

 

As a result of our conclusion, we began proactively managing the second project.  Now, six months later, most of the fire drills have disappeared. In examining daily timesheets, I have calculated that the total hours of management time actually decreased.  Proactive management also greatly increases the trust in the relationship between the computer consultant and the user, which dramatically increases client satisfaction, and opens the door for follow-on systems work.  We have now made it company-wide policy that every client is proactively managed. 

Areas of Improvement

Good project management leads to improvement in many areas of a software development project.  Some, such as quality assurance may seem obvious. Other, subtler benefits were discovered that also greatly contribute to overall project success.

A. Quality Assurance

Proactive project management is also important because it increases software quality through every phase of the system development lifecycle.  A system is not successful just because there are no bugs in it.  It is a successful system when it provides the functionality that the users required, and the users are happy with the system.  It is entirely possible to build a bug-free system that the users are unhappy with because it doesn’t meet their needs.  In a project that has been proactively managed, the quality of the delivered product is substantially higher, as perceived by the customer, as a result of having received what they asked for.  This increase in software quality leads to improved customer satisfaction. 

B. client Satisfaction

Client satisfaction is additionally increased through weekly status reports and meetings to ensure that the customers know what to expect, and when to expect it.  These two simple techniques can be used as tools to set the client’s expectations, and then, hopefully, surpass those expectations. 

C. Troubleshooting

Project management allows for early identification of problems.  If there is a mismatch between what the customer wants and what the developers are coding, it will surface earlier if there is proactive project management in place.  Project managers do this by insisting that requirements be documented, and signed off by the client, prior to allowing design and coding to proceed. 

D. Supervision

Proactive project management allows for increased control of the work and the process.  If there is no active management, how does the manager know what his or her developers are working on?  How can good developers be identified and rewarded if there is no active management to identify which ones are working most productively? 

E. Human Resource Issues

Implementing a project management methodology also reduces the impact of project personnel turnover, as each phase of the system development lifecycle is codified in the work process itself.  High quality talent is always in scarce supply.  By employing a project planning program with frequent current status reports, the project manager will be able to hire a new developer and tell him or her what to do, because the project manager will have been aware of the skill level and task assignment of the previous developer. 

F. Cost Controls

 Detailed project planning also contributes to better cost analysis and bidding accuracy.  Detailed project plans capture information such as time taken to perform a specific task.  When these are captured at the micro level, they can then be aggregated to a higher level.  When time and labor level categories are tracked, they can then become the basis for providing cost projections which support accurate project bidding.  Detailed project management prevents underbidding of specific jobs.  Work can be accepted or declined based upon cost analyses, rather than a sophisticated guesstimate. 

 

Detailed project planning can be so successful that firms bid and hire managerial talent in addition to technical talent.  It has been our experience that when we work alongside an internal Information Systems department, we provide not only technical leadership and support but also project management leadership and support.  We provide detailed project planning not only for our tasks and responsibilities, but also for the client-side tasks and responsibilities. 

 

All of the factors mentioned above are important reasons for undertaking proactive project management. Prioritizing the importance of each of these may vary slightly from project to project but all are ultimately necessary to ensure project success. 

 

The Project Management Process[1]

There is more to project management than simply writing the project plan, hence we call it the project management process.  The steps in this process are as follows:

 

·         Identify and define customer expectations, contractual requirements, and deliverables 

·         Identify the players 

·         Write a detailed project plan

·         Ongoing activities that occur continuously throughout the life of the project: 

·         Updating the project plans

·         Holding internal status meetings

·         Chairing external status meetings with the client

 

Identifying Customer Expectations and Contractual Requirements

Identifying and defining customer expectations and contractual requirements is a critical part of the project management process.  Never assume that expectations and requirements are known.  If they are known because it is standard business practice for the project manager to not only know the contract, but to be involved in its actual negotiation, that is good, but often unusual.  Expectations might not be known for several reasons.  Someone else may have initiated the project, and there may have been inadequate internal communication.  For example, a sales person may have made the sale for the company, and relayed some unrealistic expectations in order to win the business.  The project manager has to develop the plan, requiring some repositioning of customer expectations, but this has to be done.  It is better for the customer find out about changes in the project’s scope, deliverables or costs sooner rather than later.  Even if the system is for an internal customer, someone else may have set the internal client’s expectations.  These need to be managed as well. 

 

Ideally, the project manager should be involved with negotiating the contract, including the dollars budgeted, as well as have it in possession, in order to effectively own and manage the project.  This puts the project manager in the position of knowing and advising the customer about the cost of changes to their project.  It is surprising how many “must have” features are scaled back when the client hears what those features will cost.  It is highly recommended that there be a formal, written requirements document.

 

Identifying the Players

The next important step in the project management process is to identify the key players as early as possible.  There are a number of different roles, and it is necessary to determine which people in the client organization fill which roles.  It is important that each one of these be identified in every project. 

 

There are two roles in the client that represent ownership of the resulting system:  a legal representative and a financial representative.  Not identifying one or more of these roles could put the entire project at risk.  The legal person, who may or may not be a lawyer, is the person on the client side responsible for reviewing the contract, which will have ownership clauses in it.  As ownership of intellectual property continues to increase in importance, it is critical to establish a good working relationship with the legal representative.  The other person who represents ownership is the financial representative.  This person is the one who is paying for the system, and will therefore have strong feelings about owning the system.  Clear and open communication with the financial representative can be helpful to ensuring timely financial payment. 

 

There are three additional roles that need to be represented, in either the client-side or the end user group:  a Subject Matter Expert, an End User, and a Maintainer.  The Subject Matter Expert is someone who knows the end result of what the system needs to do and helps define it.  The End-User is the person who has to use the end-result system once it is delivered.  The Maintainer is the person responsible for the “care and feeding” of the end-result system.  This person often has to fix the system when it breaks, make enhancements to the system, and maintain data. 

 

Designing Detailed Project Plans

After identifying the players, the next step is to design a detailed project plan.  A common hindrance to achieving this goal is the perception that a detailed project plan cannot be created because it is not known at the outset exactly what system is going to be designed and built.  One suggestion is that expectations and requirements should then be revisited and defined in further detail.  Once a requirements definition, analysis document, or statement of work has been agreed upon, the project manager can then begin to design the project plan. 

A project plan consists of the following components:

·         Identifying the work breakdown structure

·         Estimating effort and duration

·         Identifying task dependencies

·         Designing a schedule

·         Assigning resources to tasks

 

Identifying the Work Breakdown Structure

The work breakdown structure allows a person to identify the major activities, and then detail specific tasks.  For developing a computer system, the work breakdown structure consists of the various phases of the system development lifecycle. 

 

 

The first step in designing the project plan is to identify all of the work that needs to take place, in as much detail as possible.  A system development lifecycle methodology helps to frame the tasks and identify the major activities.  The level of detail included depends upon the kind of control that the manager wants to exert. 

 

The more details there are, the better.  For any mid-size or large systems development effort, it is very easy to forget tasks.  If tasks are forgotten, there is no time or duration allocated to them, they do not appear on the schedule, and no person is assigned to work on that task.  An important part of planning the project is to remember all of the hundreds of details that must be taken into consideration in order to build and deploy a successful system. 

 

In addition, a high level of detail helps to improve software quality.  We have found that it is helpful to include three entries in our project plans for every task:  one line entry for the task itself, a second for audited or reviewed, and a third line for task revisions based upon the audit or review.  Additionally, for every group of tasks, we have two more entries:  one for code review, and another for revisions to the code review as shown in Figure 1.  When different people have different responsibilities, providing an entire system of checks and balances, it is the overall system that is responsible for generating successful information systems. 

 

 

  Figure 1: Sample task list

 

Finally, it is useful to identify milestones that occur early in the project, as well as milestones that occur at the end.   

 

Estimating Effort and Duration

Effort is the length of time (the amount of hours/days/weeks) a task takes, while duration is the period of time required to complete the task.  Effort is also known as a labor estimate.  The estimation of effort should be based on the following factors:

1.       the level of customer involvement

2.       the past experience of the developer

3.       the project manager’s past experience

4.       a project manager outside the project 

 

One of the ways to determine effort is to ask developers how long a particular task will take them.  However, this estimate needs to be considered carefully.  Different people will respond with different estimates.  For example, there are optimistic or “hot shot” estimators.  These individuals will chronically underestimate the time it takes to complete any task.  For these types, any task becomes a race to the finish line.  Providing a short time for effort is to be preferred over providing a long time, because a short amount of time “wins”.  Conversely, there are pessimistic or “padder” estimators.  These individuals will chronically overestimate the time it takes to complete any task.  For these types, any task becomes a big priority that requires tremendous amounts of time to accomplish. 

 

The effort estimate of the developer should be mitigated by the past experience of the developer, the project manager’s past experience, as well as a project manager outside the project.  It is the responsibility of the project manager to provide as good an estimate for effort as possible.  It is not sufficient just to take the estimate that a developer makes. 

 

Once the length of time has been estimated, duration is then estimated.  Duration is also known as time span.  Duration also takes into account factors such as holidays, vacations, and sick days.  In addition, there may be some gaps in the work process.  For example, with the review tasks, the actual effort might only span eight hours, but the duration might last one week, as the senior manger to do the reviewing is off-site or otherwise unavailable. 

 

Similar to effort, the duration estimate should be based upon the following: 

·         Developers’ current workloads

·         Past experience of similar projects

·         Project manager outside the project

 

Identifying Task Dependencies

The next step in the project plan is to determine which tasks should be done first.  Identifying the order in which tasks occur is also known as task dependencies or precedence relationships.  This is an important step, as some tasks have to be finished before others can be started.  However, keep in mind that, very rarely, do systems get developed in the straight, linear fashion that the waterfall lifecycle appears to imply.  For example, we have found that it is important to start planning the data migration at the same time that the applications are being designed also concurrent with the design of the reports.  Doing all three tasks at once jointly validates the quality of the data model that results from the requirements and analysis.  Consequently, it is necessary to think and plan accurately what tasks are truly dependent upon what other tasks. 

 

Assigning Resources to Tasks

Assigning resources to tasks is the next item in planning the project.  Assigning appropriate resources to tasks is an important decision, which should not be made lightly.  Assigning the wrong person to a particular task can result in an unsuccessful system.  Different people are good at different tasks, and this should be reflected in the planning process.  Sometimes it is easy, because one person is well known to be able to code forms very fast, whereas another is great at analysis. 

 

Setting a Schedule

Finally, setting the schedule is the last step that maps the project tasks into a timeline or calendar in which people are assigned to work on particular tasks.  This concludes the creation of the project plan. 

 

Updating Project Plans

Once a project plan has been written, it has to be maintained.  If the project plan is not maintained, its value decreases over time.  Projects frequently evolve differently over time from what was planned.  For example, some tasks may take longer to complete, increasing effort and duration.  If duration increases, it impacts the schedule, in that the dates to complete the tasks will be pushed further into the future.  Resources allocated to specific tasks may change.  There may be internal turnover, or people may be allocated to different projects.  If the project plan is not kept eventually, it will be so out-of-date that it will not even be useful to reference. 

 

External Status Meetings and External Status Reports

Chairing an external status meeting is a critical tool in the hands of a project manager.  External status meetings are those held with the client.  Holding external status meetings serve several purposes:

 

·         Let the client or user know the status of the project status

·         Let the owner know the status of the project status

·         Identify implicit issues of concern to the client or user

·         Communicate issues that have risen from either the internal (vendor/developer) side or external (client) side

 

We hold external status meetings with the client or user on a weekly basis. This practice is highly recommended.  The advantage of holding them with a weekly frequency is that it keeps the lines of communication open.  Sometimes, the only items that are discussed are those written on the status report.  Most of the time, however, this is not the case.  Clients make particular comments or ask questions about something that is not included on the status report or project plan.  These are the things that the astute project manager listens for and addresses.  For example, a client wants to schedule a data migration eight weeks in the future, but is displaying some misgivings about it.  Unearthing those misgivings and addressing them greatly increases customer satisfaction.   

 

The external status report is an important tool associated with the external status meeting.  There are many different types and formats of status reports.  We recommend a short 1-2 page status report, unless the project involves hundreds of developers.  If a project is so large as to employ several hundred developers, a 1-2 page weekly summary report, plus a more detailed status report should be prepared.  An external status report should include the following sections: 

1.       Accomplishments in the Previous Period (Week),

2.       Planned Activities for Next Period (Week)

3.       Comments/Issue/Concerns/Problems. 

 

The Planned Activities for the Next Period section in the external status report is important because it allows the developer side to confirm the priorities and order of the work with the expectations and priorities of the client.  It also prevents fire drills due to communication gaps between users and developers.  By explicitly have a section called “Planned Activities,” the user can approve or question these activities.  If the user then calls up the project manager two days later and says that Activity X must be immediately worked on and delivered, the project manager has a backup.  Is Activity X a real emergency, or not?  It is possible to have an urgent need, but it is unusual for a client to be unable to plan two days ahead every week.

 

It is often surprising to note the differences in perception of the status of a task from the developer’s perspective from that of the user.  Making sure that these perceptions are in agreement provides the ultimate quality check for whether a bug is fixed or not.  For example, a developer may fix a bug, have an independent tester test it, but then the revised form may not be delivered to the client.  If an independent test is missed, it will get picked up by the client, because the client knows whether or not that bug is fixed, since they use the system much more than a developer or tester ever will.  Having a status meeting puts everyone on the same page. Developers and clients/users can all agree about whether the status of any outstanding issue is open or closed. If there are differences, these can be investigated further. 

 

Finally, the most important impact of external status meetings and external status reports is to build a relationship of trust based upon performance.  When the status report is reviewed at the status meeting each week, the client or user starts to build a picture of the work and how the overall project is progressing.  As weeks in the project go by, and tasks are accomplished, the user or client becomes more confident in the ultimate success of the entire project.  The value of this trust relationship cannot be overestimated.  Many users or clients have been associated with or heard about unsuccessful projects, and it is important to show that this project is different. 

 

Aggressive Deadlines or Budgets

It is common that the project manager may encounter aggressive deadlines or budgets.  Unrealistic deadlines may arise from a variety of problems, including the following:

 

·         Someone outside the development group determined the deadline.

·         Customer requirements change throughout the life of the project, i.e. “scope creep.”

 

Sometimes the deadline is mandated by someone external to the project.  For whatever reason, the user or client comes to the information systems group with a final delivery date for the project.  One frequently cited reason for this practice is that the user’s or client’s manager has set this date, and it simply cannot be changed.  In our experience, even though the customer may say otherwise, we have found that these inflexible deadlines can and often are changed. 

 

An aggressive deadlines or tight budget can also simply be due to an underestimation of the effort involved in the project.  Users and clients rarely overestimate the time and effort that it takes to develop a system.  Consequently, aggressive deadlines and tight budgets are often the norm in systems development projects.  Sometimes even though users and clients state that the Company’s Board of Directors will not approve a time or budget extension, reality sets in and the Board actually does approve it.  Clients and users will say anything to try to make the system development take less time or cost less.  However, this approval is sometimes given because the Board is presented with a very detailed analysis of why the project is going to take longer or cost more.  The following steps in the detailed analysis have been used to counter aggressive deadlines or budget. 

 

1.       First, prepare a detailed, process-based estimate; the more detailed, the better.  The work breakdown structure can be created at this point. 

2.       The second step is to prioritize the modules and functionality.  The ones with the highest priority should be developed and delivered first, and the other modules and functionality should be developed later.  A detailed project plan should be prepared at this point. 

3.       The third step is to meet with the customer and demonstrate why a specific deadline is unrealistic within the detailed cost estimate and project plan.  It may also be necessary to negotiate with the customer’s manager and/or other senior management within the firm. 

 

Process-based cost estimates have been used successfully.  However, to be able to do these well, it is necessary for the customer requirements to be explicit and the analysis phase should be largely complete.  Consequently, although we advocate process-based cost estimates for projects, they are easier to do for aggressive deadlines and overruns because a significant amount of the analysis has been completed by then. 

 

Managerial Aspects:  People Skills

In addition to writing project plans and preparing cost estimates, the successful project manager also needs a number of interpersonal communication skills.  Some software engineering and project management methodologies do not discuss this, while others focus on team building and communication to the detriment of the systems development aspects.  Ideally, both are required.  Some of the managerial aspects that comprise the project manager’s work include:

·         Communicating

·         Negotiating

·         Decision-making

·         Task and resource allocation

·         Prioritizing

 

Communication is critical to ensuring that both the external client and internal team members are happy.  Communication involves both input as well as output. The project manager needs to be able to hear and listen as well as to speak and write.  The project manager needs to be able to hear and see things that a developer may not hear or see.  For example, because he or she is involved so closely with his or her design and development work, a developer may not hear that the client has concerns with overall system performance.  If that developer wants to advance to project manager, he or she needs to be able to communicate with the client so that the priorities of the client are the same as the priorities of the developer.  Some developers need to receive formal communication training, prior to becoming project managers.  In addition, we have found that the difference between a senior developer and a mid-level developer is that, while both can perform a particular technical task, the senior developer is able to adequately communicate it to someone else so that that other person can perform that task, while a mid-level person cannot.

Negotiating is an ongoing activity, that may include persuading developers that it is necessary for them to change a form because that is what the client wants, informally negotiating with the client as to what change request will require only a nominal increase in resources, and formal negotiation in which the entire contract (including statement of work, dollars, and intellectual property) is determined.  Decision-making occurs during all of these processes. 

 

Negotiations with internal developers typically involve task and resource assignments.  This can be tricky, as some projects may be viewed as more interesting and likely to capture top management attention, while others are perceived as more cut and dried.  One solution is to rotate people among the various projects and clients. 

 

Finally, the project manager needs to be able to prioritize tasks and balance conflicting priorities.  For developers who are working for multiple clients, the key is to be able to prioritize their work between all of the clients.  It is the job of the project manager to prevent project personnel from becoming overwhelmed by clearly prioritizing tasks. Our experience has been that people tend to feel overwhelmed if they have three tasks that they perceive to be all at the same level of priority. 

 

Conclusion

 

In conclusion, “If you fail to plan, you plan to fail.”  Without careful planning and project management, it is possible to have a technically brilliant system, but not a successful project.  Alternatively, with careful planning and project management, it is possible to have a successful project with a technically ordinary solution. 

 

About the Authors

Katherine Duliba has presented internationally at the IOUG-A Conference, the Virginia Oracle User Group Conference, the New York Oracle Users Group, the Fifth International World Wide Web Conference in Paris, the University of Hawaii, and the USA/Canada Institute in Moscow.

Katherine is a senior project manager at Dulcian, Inc., which provides Oracle consulting services and products.  In addition, she is writing patents to secure intellectual property protection for software innovations.  She received her PhD in global risk management systems from New York University, after which she estimated bank-wide operational risk monthly in the Global Risk Management Division at Bankers Trust. 

 

Craig Warman is a senior principal consultant at Computer Resource Team, Inc. (CRT), an Oracle consulting practice with offices throughout Virginia. As a former principal consultant with Oracle Corporation, Craig provided product training to Oracle consultants and customers nationwide.  He is a regular presenter at the International Oracle User's Group IOUG-A Live!, Oracle Development Tools User Group, and Oracle Open World venues, and is president of the Virginia Oracle User's Group.