Software Project Management Challenges

Software Project Management Challenges

For software project management, the most substantial issues have to do with finding requirements, managing a team, ensuring the final product works, and trying to stay within budgets of time and money. Project management issues arise in all contexts of software development, regardless of the particular methodology followed.

• Top Management Support
  
• Team Composition
  
• Vendor Selection
  
• Project Estimation
  
• Function Point Analysis

Top Management Support

Possibly one of the most important issues for software project management in the current organizational environment is of obtaining and retaining top management support. Top management buy-in to the project is required from the start, even while the project is being conceptualized. The requisite resources have to be allocated and then supported for the duration of the project.

The distinct advantages of having the top management involved are many. Large and medium-sized projects, in particular, require integration with other systems within the organization, which the top management can facilitate. The vision and high-level requirements for the software are provided with assistance from the top management, ensuring that the software integrates well with the larger goals of the organization.

Vendor involvement and selection are facilitated with negotiations at the highest levels of the organization. Also, for the organization to accept the new system, the top management is indispensable for providing the motive and rationale for the new system, ensuring personnel training, and re-assignments.

Team Composition

The team that is involved with the overall design, implementation, and maintenance of the system has to be constituted carefully. Teams have to have a balance of skills and experience in project management. Ideally, teams should last the duration of the entire project cycle, however long the cycle may be. Rules for team composition are hard to define, as they are so dependent on context. However, some avoidable issues can be highlighted as they are known to be serious problems.

• The project leader should be an individual who commits to the entire duration of the project. A replacement should be identified and groomed, in case the leader has to be away for unavoidable circumstances.
  
  
• The skills of team members should be carefully documented and made known. This will ensure that others know who can do what, and so they can call upon them when needed.
  
  
• Team members should be comfortable working with each other. More importantly, if there are known problems with individuals, they should be addressed early in the project by the management.
  
  
• The leader should have overall accountability and responsibility for the project. He/she should be the person one is to turn to if things are not going well. The leader should also be the person to be held responsible if the project fails.

In modern, large organizations, it is often the case that teams are distributed across the globe and work jointly using electronic networks for communication. System building assumes a more difficult form in such situations, although the above critical concerns have to be addressed.

Vendor Selection

Organizations nowadays use vendors extensively to build and help maintain their systems. Vendors are often hard to identify, particularly those with special skills. Industry associations provide directories that list software vendors and their skills. In India, the National Association of Software and Services Companies (NASSCOM) is a well-known association that maintains a database of vendors. This is a good starting point. Most client firms will make it a point to evaluate a vendor thoroughly before they are selected. Some points for evaluation are:

• The number of projects the vendor has completed of a similar nature in the past. This should also include the size of the projects, the time taken for completion, the kind of technology used, and whether the clients were satisfied with the project.
  
  
• The skills base of the vendor depends on
  
  • How many employees have particular skills,
    
  • how many have been with the firm for long,
    
  • what has been the training imparted to them, and
    
  • how have they gained experience?
    
    
• A site visit to the vendor’s premises to see the working conditions as well as the assets the vendor has to use for the work. This would indicate how deeply the vendor can commit to the project.
  
  
• For long-duration and large projects, the financial position of the vendor should also be evaluated. Some firms demand bank guarantees from vendors against successful completion of the project. Only financially sound vendors can produce such guarantees. As small vendors cannot produce such guarantees, the client organization has to rely on financial records to assess the vendor.

It is also important that tenders and call-for-proposals floated to ask for bids from vendors should not be biased to favor one or the other vendor. The wording of the tenders has to be vendor-neutral, particularly avoiding words or phrases that identify with a particular vendor.

Project Estimation

At the initiation phase of projects, one of the most difficult problems managers face is estimating the size of a project. This entails estimating the resources that will be required by the project and the effort involved. The entire planning for the project is based on these estimates and if they are wrong, the project’s success is jeopardized.

Project estimates can be over or under. If they are overestimated, it means that the project will eventually take fewer resources than planned. If underestimated the projects will take more resources than planned. Some argue that it is better to overestimate than to underestimate, as excess resources are not a problem but fewer resources are.

For vendors who are bidding for a project, overestimation leads to a high-cost estimate for the project thus making their bid potentially uncompetitive. If their bid is an underestimate, which they also win then they will incur higher costs for the project than they had bid for, thus cutting into their profits.

For client organizations, overestimation leads to committing resources more than required, thus leading to higher costs and management problems; underestimation leads to scarce resources that have to be procured, possibly at a high expense.

Function Point Analysis

This is a technique to estimate the size and effort required to build an information system. The estimate is given by one measure, called the function point, which shows how complex the project is. For example, a project with a function point of 200 can be estimated to be built in a certain number of person-hours. This estimate is independent of the platform and software tools used. The function point estimates are based on two broad categories of computing requirements:

• Data Functions: It indicates the variety of data input and output needs and how they have to be built.
  
  
• Transaction Functions: They indicate the processing required within the system. Transactions are categorized into various sorts such as communication, manipulation, writing, etc., and the efforts required for these are then estimated based on some industry benchmarks.

Function point analysis is quite effective in providing an estimate of the size and complexity of the system. However, it cannot account for project-based specificities such as changes in the project scope and requirements, skill levels of developers, availability of platforms, and so on.