Software pmi

Also, once the software is deployed and all possible deployment problems are resolved, Operations is the organization responsible for the Life Cycle Management of the software. Just as the testers do in the lab, they want to make sure that nothing previously working has been broken when the new software is deployed. They are the overseer of all the projects. Their main role is to ensure the on time delivery of the software.

Their role is to assist the Release Manager when he or she hits a bottleneck. They are not an active Release Team member but are kept in the loop on all release activities. Their stake in the software Release Management is to ensure that all dependencies are satisfied. Often there are more than one system involved.

System Engineering manages the interfaces. Along with Operations, they are watching out for possible break in existing systems. They are part of the Release team.

Sometimes it is necessary to procure a third party software that will be integrated in the package being developed. It is the responsibility of Procurement to negotiate third party contracts and purchase required hardware and Software. They are not active members of the Release Team. They can be summoned to be present at a particular meeting by the team, or they may appear on their own if they have a relevant issue to discuss.

They hold the moneybag. They control the cost of the Release from a to z. They approve, or disapprove, all expenditures. They make their decision based on what is best for the business. They may decide not to fund a release because in their judgment it is too expensive or not in the best interest of the business at a particular time. Finances is not an active member of the Release Team, but just as Procurement they may be summoned to be present or they may appear on their own.

Billing's responsibility is to ensure that the capabilities being offered by the new Release are properly billed for. Usually, billing release schedules are different from systems release schedules. Usually, billing will create hooks into the systems Release in order to generate bills for the new features. Billing does not actively participate in the Release Team meeting, but can be called in to discuss the impact of their activities on the Release.

Sometimes not being able to bill may delay the deployment of a release. The Customer Support team is the one that gets the calls if anything goes wrong. They want to make sure that they understand everything about the new Release and that they are properly trained, on all levels, before it is deployed. They are an integral part of the Release Team.

Legal is not a member of the Release Team but often enough is called upon to provide guidance to the Procurement group in their negotiations with third party vendors. They are also called upon by Sales when an agreement has to be reached with a customer regarding testing.

It is possible for the Release to be delayed while waiting on Legal to provide the support to complete an agreement. The content of a release may come from different sources identified as functional groups. The FPR process is the mechanism through which the requests from the functional groups are processed.

Often enough, changes are made to documents at various phases of the Release cycle, and those changes are not made known to all who need to know. The following sections describe the manifestations of these apprehensions, which subsequently lead to dissatisfaction.

Price tag and operational costs of maintaining specialized project management software are often quoted as a major concern by many project managers. The selection of a particular application is quite often dictated by the project owners while the bills are paid by the contractors. Project managers employed by the contractors frequently question the return on investment for deploying an expensive software application.

The infrastructure and resources required to maintain software applications also cause apprehensions. Depending on the size and scope of the project, self-hosted applications require specialized facilities and enclosures that inflate the overheads in terms of finance, manpower, and effort.

The time and effort needed to learn the intricacies of specialized software applications also factor among the concerns often raised by project managers. A PMIS that lays more emphasis on automation, using software, will in turn necessitate that all project management team members and many project team members are trained in the use of software. This study was carried out to explore and report the perceptions of project managers in the EMEA region.

This study aims at achieving the following objectives:. This study was carried out using a survey in which respondents were selected from all over the EMEA region ensuring representation of all regions and industries. Respondents were given a list of common features and tools found in most project management software applications and they were asked to order the list based on relative importance of items.

Each respondent was asked to select the features or tools used most often as well those used least often. Respondents were also asked to list the shortcomings in their own software applications as well as provide a wish list of features or tools that are likely to facilitate effective utilization of their PMIS. Respondents were also asked to indicate their level of satisfaction from the software application currently in their use.

The survey was carried out during the months of September and October of Findings were processed and compiled in November The demographics of respondents are given in Exhibit 3.

The partial list of common features and tools that was rated by the respondents is given in Exhibit 4.

The top 10 features and tools used most often, based on the aggregate ratings from all geographies and industries, are given in Exhibit 6. Examine the way that you manage projects. Figure out what kind of scheduling, resource planning, and cost control you do now, and what you would like to do. To do this, you should consider the following actions. You will want to ask such questions as: Do I manage or participate in more that one project at a time? Do I need critical path scheduling?

What kind of time units do I use days, hours, weeks, shifts? Are resources and costs integrated into the schedule, or managed separately?

If the later, do I want to integrate them in the future? This is certainly advisable. What kinds of reports do I issue and to whom are they issued? Do I manage resources across projects? How do I resolve resource conflicts? The objective here is to develop a needs analysis. Once these needs are identified, you can convert them to a project management software selection specification.

Then you will be better able to sift through the volume of available software, as you will have a better idea of what you are looking for. Your needs will drive the selection process, rather than the general attractiveness of the available products, or vendor hype. In order to develop the project management software selection specification, you may wish to consider the following activities:. In order to better understand the available options in today's popular project management software, let's look briefly at the general makeup and functionality of these products.

The first thing to address is the question of functionality and usability as a function of the computer platform. When project management software was first developed in the late s, the basic computer environment consisted of mainframes. The user communicated to the mainframe via punched card input. Later, as the so-called minicomputers came into vogue, many megaprojects were able to dedicate the entire computer to management of such projects, and considerable project management software was developed to support this environment.

Now, the most common project management situation consists of smaller but multiple projects, and there has been a solid shift toward use of the microcomputer for project management applications. The Macintosh has received increased attention recently, growing from about three popular products in to almost a dozen in early A few vendors also support the Unix operating systems.

But the overwhelming choice of developers and users of project management software is the PC. Within this platform there are several options.

One concerns the screen environment, where users now have a choice of character-based or graphical pixel-based approaches. The latter is often referred to as a GUI graphical user interface. While Microsoft's Windows is the best known GUI, many project management software developers use their own design to embed the graphical capability directly into the basic DOS environment.

The systems that use a GUI will generally be more pleasant to use, as the finer resolution of the bit-mapped display can present more data in a more attractive and readable manner. But the GUI need not be a dominant item in your list of criteria.

The other key option is product power, which can be described as the combination of product functionality and flexibility. For the PC platform, there have traditionally been two basic levels of power. These products usually try to bring mainframe power to the PC, and, for the most part, have succeeded in doing so. Certainly, there are differences in the PC and mainframe capabilities, but these differences are more likely to be a direct function of the platform speed, capacity, number of users, etc.

There are also several products that are for DEC platform only. They may be able to offer high-end functionality while bringing the inherent user friendliness of the PC to the user. While most of these products could be quite a stretch for the novice user, they have been incorporating GUI-type interfaces and other visual and operational aids that help to make the programs more responsive and less intimidating than they used to be.

I keep hearing about the impeding demise of project management software vendors. Yet, we are not seeing vendors falling like flies—in fact, most of the established developers continue to provide products and services.

Several nonmainstream vendors were not present in the exhibit hall, but, as far as I know, most are still in business. There are three things that I can think of that contribute to the overall health of the project management software business.

One is that there is so much growth in the market that there is still room for the number of viable suppliers. Second, no project management software product comes close to being the perfect solution for all users. Even within an organization, diverse needs could easily dictate multiple product solutions. Also, as strong as today's project management software products are, in both functionality and usability, all appear to make tradeoffs. My perfect solution would be a combination of features from many products.

Therefore, there is still room for the various vendors to attract users to their camp. Third, many project management software vendors derive a good portion of their revenue from support services rather than the software itself. Although sales of some of the older, host-based products may have slowed, there remains a sufficient revenue stream to maintain vendor viability, and to enable the developer to maintain the product and clients.

While many of the project management software products can be considered to be general-purpose tools, there are others that aim to address a specific set of needs. These might fall into the category of industry specific needs such as MIS or functional needs such as accounting or risk management.

Schedule Publisher is a highly graphical task and resource scheduler with an emphasis on the latter. Schedule Publisher facilitates visual leveling of resources via a multi-resource graphic display, while providing traditional CPM functions.

These products support the Windows, Macintosh and Unix platforms. Dekker, Ltd. They recently announced a bridge to the Primavera Project Planner scheduling system. Mantix, Inc. Data is maintained in Oracle, and can be accessed from X terminals or PCs. Marshall Technical Services is moving into project management software products in addition to their project management consulting work. Robbins-Gioia, Inc. A significant segment of the project management software market falls into the category of add-ons.

Many of these are add-ons for Microsoft Project, but other mainstream scheduling tools are also supported. There are two basic types of add-ons, with several varieties in each. The first group is designed to either supplement functions that are missing from the base product or to extend the product into special, non-traditional functions. The second group I call them Consolidators are designed to bring data from multiple projects into a common SQL-based database for further analysis and processing.

The program can determine the probability of meeting any completion date and highlight the higher-risk paths which may not be the same as the critical paths. Many people feel that such evaluation of risk is essential before betting on a project completion date see my October PM Network column.

We will have more on this product and subject in future issues. CMR Publishing, Inc.