Both sets of dates are important for determining the critical path. Tasks on the critical path have matching early and late start and stop dates, thereby indicating no opportunity to let those tasks slide. If they do slide then completing the project on
time is impossible unless corrective action is taken. Another characteristic of tasks on the critical path is that they occupy the longest path in the diagram.
The network diagram works best for managing the details of a project. Under some circumstances, such as reporting to upper management, a simpler, easier to understand schedule is preferable. Exhibit 6 displays a schedule called a bar or Gantt chart. It does not show the dependencies and only shows the early start and finish dates.
Exhibit 6. Bar (Gantt) Chart
Organizing
Communication and infrastructure are two key elements in organizing a help desk project. Both ensure that the project is executed according to plan efficiently and effectively.
Communication This element has two parts: documentation and meetings.
Documentation entails developing any material that proves useful for managing the project. Typical documentation includes forms (e.g., time collection), reports (e.g., status report), procedures (e.g., change control), and reference material.
Often this documentation is collected and then filed in project history files. These files serve as a repository of information about the history of the project, from inception to completion. This information can prove useful for analyzing problems and learning from experience.
Meetings are of three basic types: checkpoint review, status review, and staff.
A checkpoint review meeting is held after completing a major milestone (e.g., completion of a phase). Its purpose is to learn from the experience up to a specific point in time and decide whether to proceed.
A status review meeting is held regularly to determine progress against the project plan, from a cost, schedule, and quality perspective. It is preferable to collect status prior to the meeting so people can discuss issues intelligently.
A staff meeting also is held regularly. Its purpose is to share information and experiences. Often times, the staff and status review meetings are held together in the same session to reduce the number of meetings and the time spent in them.
Infrastructure This element deals with applying resources in a manner that maximizes output. One approach is to set up a project organization, which is reflected in an organizational chart. The organizational chart should provide a reporting structure and clarify roles and responsibilities. The organization should incorporate basic management principles, such as span of control, unity of direction, and accountability.
Another approach is to publish a responsibility matrix as discussed earlier. The matrix helps to clarify responsibilities and the extent of involvement. Publication breeds commitment because it gives visibility.
Still another effective approach is to establish a project office. Depending on the project’
s size, of course, the project office is a place for holding meetings, storing documentation, and displaying information. A good way to display information is to set up a visibility wall or even a room to display plans, architecture, and other key information of the project. The wall or room then turns the project office into an effective communications as well as administrative center.
Team members and customers of help desk projects will find the visibility wall or room useful. With plots or diagrams on display, they can see the overall structure of the help desk center, its services, its procedures, and the impact on the business.
Controlling
It is rare that a project proceeds according to plan throughout its life cycle.
Frequently, variances from the plan will occur, either from a cost, schedule, or quality perspective. Keeping a pulse on the project, therefore, is critical to ensure adherence to the plans. This involves performing the following four actions.
Collecting Status Data This action will occur just prior to or during status review meetings. Data should come from the people responsible for their respective tasks.
Assessing Performance After collecting and compiling the status data, determine whether a variance or deviation from the plan has occurred and its criticality. The variance will come from one or more of three areas: cost, schedule, or quality. For cost and schedule, project management software can help determine the impact of a variance.
Taking Corrective Action If a variance appears, the next action is to decide whether to take corrective action. Corrective action might entail working overtime to get back on schedule or pursuing a complete replanning effort for the help desk project.
Managing Changes With movement, goes an old saying, comes change. A project environment constantly is moving and changing. Project managers must deal intelligently with those changes; otherwise, they constantly will fight fires. It is important, therefore, for project managers to establish an infrastructure to capture, prioritize, evaluate, and dispose changes. This action involves going beyond using configuration management software. It also deals with organizational and behavioral changes, something help desk projects must continually reconcile with their development plan.
Closing
All projects end for many reasons. They may last so long that they lose their relevancy to the customer. They may lose their funding. They may have achieved their goal(s). Whatever the reason, it is important to close as efficiently as possible while remaining effective to the very end. It also means learning from the performance so that history does or does not repeat itself on similar projects in the future.
When closing a project, therefore, it is important to perform several actions.
Converting Data into Information Throughout a pro ject, if organized well, it will accumulate data. This data must be converted into information. This information is useful to track performance and identify what did and did not go well. With this information, project managers can determine the overall success or failure of the project. It also enables preparing the lessons learned.
Preparing the Lessons Learned This document captures the key experiences of the project team so that future projects can capitalize on what to do and not to do.
The lessons learned should cover business and technical topics.
Releasing People Although keeping an inventory of people to handle contingencies provides a comfort level, it is more efficient to retain only the necessary individuals to complete remaining tasks. Having too many nonproductive people adds unnecessary costs and lowers the productivity of the people with remaining work. It also prevents people from working on other projects that could use their skills.
CONCLUSION
Building an IT help desk was once seen as a dead-end route for IT professionals.
Today, just the opposite is the prevalent viewpoint. A help desk serves as an information hub for answering questions and solving problems that are business and technical in nature. It is imperative, therefore, that a help desk project results in an organization that provides timely, meaningful services to its customers. Project management is the tool to ensure that occurs.
Chapter 36: Leveraging Developed Software: Organizational Implications
Hal H. Green
Ray Walker
OVERVIEW
Leveraging is the reusability or portability of application software across multiple business sites. The extent to which an application can remain unchanged as it is installed and made operational at each location is referred to as leverageability.
Leveraging can reduce the cost of acquiring and maintaining application software.
However, the ultimate measure of leveraging is the resulting business benefit — the cost of delivering a working capability from site to site across an enterprise.
Whether a manufacturer chooses an off-the-shelf or custom software solution, achieving leveraging requires the cooperation of multiple sites, beginning with the initial phases of the process. In downsized companies and companies with greater decentralization of decision making, this type of businesswide effort can become difficult. This is especially true when the application is not necessarily a supply-chain-level application but one affecting more directly the manufacturing process.
ASSESSING PREPAREDNESS FOR LEVERAGING
Where a leveraging opportunity exists, limiting the scope of the target sites to a common business, product type/configuration, or other shared interest may mitigate some of the management challenges to leveraging. This strategy constrains the leveraging activity to sites that are likely to benefit most. These sites are likely to be willing to compromise on functional requirements to realize the reduced costs of acquiring and supporting the leveraged application.
Analysis Team Responsibilities
Leverageability of software is affected by the initial choice of platforms. Ideally, the application should result from a rigorous data and function modeling phase that clearly depicts the natural systems of the sites. All too often hardware, operating systems, and database platforms are the decisions that precede, shape, and limit the follow-on choices. As is the case for all good design practice, business requirements should drive technical architecture, not the other way around.
If a solid data and function model exists for each site, the choice of acquiring or developing software becomes clearer. When an off-the-shelf application exists serving most of the business needs, then the choice becomes a selection between vendors’
offerings relative to the specification. When no commercial offering exists on the market that satisfies the site information model, then new development or modification of some existing software is the obvious choice. In either case, the following questions are germane to understanding the number of sites that can apply the application to be acquired or developed: