Keeping Projects on Track

ABSTRACT.

              Technology may advance at a breakneck pace but humans are still involved with implementing it. This paper seeks to identify four areas of significant risks that can and do impact software project schedules. It also suggests methods for handling these potential bumps in the timeline. In the conclusion of this paper it will be shown that even though these risks are ever present, preparation before hand can minimize their potential impact to a tolerable level. 

 

Introduction

              Why is that with all the Technology at hand, the mere delivery of a piece of software can go from a beautiful ensemble to a never ending rubbish pile. Managing a software development project asks the project manager (PM) to set out on a journey with the knowledge that the path to be taken, what is to be brought and the final destination are not completely known. How often will he sit in a meeting room listening to the reasons for a project delay while comparing this to waiting at a railway station on a cold winter evening, for a late train only to hear the station announcer say “A cow was on the track, all trains are now delayed”?

              PM’s are judged on what they deliver, when they deliver it and were the costs within the approved budget. A risk that seems insignificant at first can easily destroy all that went before and comes after.  Understanding the risks a project can encounter that will affect its schedule will help provide the intelligent PM with a shield that will allow him to survive another day in the Software Development World.

              It is hoped that this paper will go a long way to helping the PM that reads it build his defences, deliver the software the client wants, when he wants it and not bankrupt the software company in the process. For all those that have survived a project at the helm, this paper sets out to heal your wounds before the next task.

Considering Risks

            Knowing what risks you are likely to face is not enough by itself. “you can misspend in an overblown effort to mitigate risks that will never come to pass or that won’t cause much damage if they do.” Geer (2006). A PM has to determine the severity of the risk they face or their whole project might not go anywhere as they spend their time eradicating every risk. As Geer (2006) states, knowing the potential impacts of identified risks helps to determine the effort to be spent and this is achieved through approved and agreed upon metrics by all stakeholders. Not all is lost when a risk is encountered during a project as a positive benefit can be obtained. “Keep track of the risks that actually come to pass during a project so that you have a better idea of their probability during your next project.” Geer (2006)

1 – Lack of Resources

What is a resource? When managing a project, the humble staple could be considered a resource as it holds together the project documentation but I have never known of a project to be late due to lack of staples. When you think about what resources in the life of a project can truly impact it, you end up with: Time, Money, Software, Hardware, Space and People. As this paper deals with impact to schedule, we will now consider how the other previously mentioned resources impact the time resource.

People

Projects need people to complete the tasks. “Human capital management problems were also identified as critical to successfully implementing” (GOA, 2006, p4). PM’s have to anticipate the number, when they will be needed and the experience of the people required to complete the development. At the beginning of a project the PM is dependant on his own experience and that of those around him to determine the people needs of the project. Once he has established the staffing needs the next issue comes with fulfilling them. The project can be delayed by not being able to find enough bodies to fill the positions, experience that matches the skill set required and turnover of project staff. As the number and experience of staff required to complete the project increases so does this risk of the project not meeting its delivery date. “By not identifying staff with the requisite skills to implement such systems and by not identifying gaps in the needed skills and filling them, agencies reduced their chances of successfully implementing” (GOA, 2006, p4).Y2K was a good example of a shortage of staff to handle all the date changes in code throughout the world.

Strategies for handling people risks

1.      If the project has a need for a large amount of skilled staff, searching locally may not meet the needs, delaying development. “Incomplete and ongoing staff shortages had played a role in key deliverables being significantly behind schedule” (GOA, 2006, p 22). Today’s world of off shoring gives access to a greater pool of skilled resources than ever before. By contracting with a company such as InfoSys that specializes in recruiting large numbers of skilled staff throughout the world, you should be able to meet the largest demands for people resources.

2.      Risk of having a resource when needed can be reduced by the instigation of the hiring process well before the requirement and hiring the resource as soon as they are found.

3.      Experience of staff should always be verified before they are hired to avoid the unpleasant risk of a resource being unable to deliver (Think of Michael Brown – former director of Federal Emergency Management Agency). Ensure that strong, replicable procedures that validate resource knowledge are utilized for all hires where experience is critical. It should also be noted that a more experienced person might be able to deliver components of the project quicker than a less experienced person.

4.      Determine if resources will need special security clearance as this can take weeks, months or years to obtain.

5.      Turn over of staff risks can be minimized by being aware of the stress of the environment and working to minimize it. Critical staff should be well taken care but the PM should also consider quick replacements options for them should they leave. The theatre has this process well established by using understudies to the lead performer.

Software & Hardware

Time has moved on since the days of punch cards and now developers expect to be able to have access to software and hardware to help them develop. Other people on the project team such as Testers will also need software and hardware to meet their needs in the project life cycle. To avoid having people resources sitting idle, the PM needs to consider the software & hardware his resources are likely to need to do their jobs.

Strategies for Software & Hardware Risks

1.      Ensure that the people resources have the software & hardware that they need for the role they perform by identifying early on in the project what each role needs.

2.      Offer the option to work shifts and this way two or more people could share the same equipment & software.

3.      Develop processes for on boarding and off-boarding people from a project so that the minimum amount of time can be spent bringing a resource on or off line.

4.      Hire companies that supply their contract employees with their own hardware and software. IBM provides their consultants with laptops.

5.      When developing on servers, check early on with the system’s people to ensure that the servers have enough physical resources available to support the development project. There is also a need to make sure that the additional staff can be accommodated on the network.

Space

If the project the PM is working on is a large one, they may encounter the problem of office space. I experienced this recently myself as I tried to find room for over a 100 contractors at short notice. Finding space that meets technology needs in a limited geographic area can be very challenging. Other considerations for space can relate to new hardware being put into an existing computer room.

Strategies for Space Risks.

1.      Offer the option to work shifts and this way two or more people could share the same space.

2.      Hire people resources from companies that have offices within the geographic location that you are willing to work with and they may be able to set up contractors in their own office space.

3.      Allow remote networking into the office and people could then work from home or any another location in the world.

4.      Re-design the floor plan of the current office to provide more office space prior to the project getting underway.

5.      Ensure that the company’s computer room has space or is expandable if new server hardware has to be brought in to support the project.

Money

People do not generally work for free. For the PM to deliver his software he needs to have a budget that will pay for all the resources he will need. If the PM goes over budget, staffing may end up being reduced to compensate with the risk that delivery dates for the end product will be missed.

Strategies for Money Risks.

1.      Minimize expenses by engaging resources as and when they are needed. Hollywood does this with extras for the movies.

2.      Save on software license costs by ensuring that only the people that need it have it. At $15,000 a seat for Abinitio Developer licenses, it would not take long to blow a budget out of the water.

3.      Establish an approved budget up front using input from expert resources. By having the budget approved, time will not be wasted by the project being held up as money is sought.  The use of expert resources to prepare the budget will also help to ensure more accurate figures.

4.      Use off-shoring resources, as there costs can be less.

5.      Engage companies that supply their employees with resources such as hardware & software so that your budget does not have to cover it.

6.      Accurately track spend rate to budget so that issues with cost can be dealt with early. Even the American Government has been known to shutdown due to budget woes.

2 – Bad Requirements / Scope Creep

                “Good requirements are the underpinning of any project.” (Turk, 2006, p1). What is a requirement? It is like a weekly grocery list that contains the essentials for us to survive another week. If we miss something from the list then extra time has to be spent to obtain it or we have to suffer without that item. Scope creeps is where we deviate from the list and start to purchase additional items that are usually not necessary (Chocolate Ice Cream) “on average, there is about a 25-percent increase in requirements over a project’s lifetime” (GOA, 2006, p58). For the PM, bad requirements & scope creep can be their worst nightmare as the design of the software is based on the initial requirements identified. Changes at a later stage can impact the whole development done to date and throw a ‘Cow’ on the track causing the delay or even death of the whole development. “Killing projects that exhibit those risks on Day One would save most IT organizations 50% of the money they spend on failed projects.” (Geer, 2006). “Between 40 and 60 percent of all defects found in a software project could be traced back to errors made during the requirements development stage.” (GOA, 2006, p58)

Strategies for Bad Requirements & Scope Creep Risks

1.      Hire or use experienced Business Analysts that have a proven track record of getting requirements from users, analysing and documenting them.

2.      “Requirements are stated in clear terms that allow for quantitative evaluation.” (GOA, 2006, p48) Only one understanding of the requirement should come to a readers mind and to verify that they have been met, they have to be quantifiable.

3.      GOA (2006, p40) suggests the generation of Business Process models creates better system requirements.

4.      Hold regular reviews with the business of requirements documents to verify that what they think they need is captured correctly.

5.      Instigate change control procedures to limit Scope Creep to only necessary items. The procedures should review the impact to the project of the additional items and state who will have the ability to accept or reject.

3 – Unproven Technology

            Sometimes the software needs of the business supported exceed the current technology used for development. Or sometimes a software tool hits the market that seems to be everything the business wants. “Too often, an important project is started using a technology with no proven capability or with which no one on the team has experience.” (Turk, 2006, p3) Several times, I have witnessed companies attempt to move data off of a Indexed Managed Sequential Data Store into a Relational Database only for them to have to give up on the Relational Database as its performance did not equal the original. As the title says, ‘Unproven Technology’ is unproven and does not have enough history to verify that it will indeed work for the task demanded of it.

Strategies for Unproven Technology Risks.

1.      Determine acceptable performance and test the New Technology against those parameters.

2.      Implement in a phased approach rather than a big bang approach so that metrics can be gathered to ensure the New Technology can deliver.

3.      Consider plan B’s should the New Technology not work, such as developing an alternative software in parallel.

4.      Hire the most experienced staff at using the New Technology so that time is not wasted learning.

5.      Let another company implement before starting your project to see how well it goes with the other companies.

4 – Communication

            Without communication, there is no way that the PM can be aware of project status, issues or concerns. The PM also has to be aware of other projects going on around him, any of which could affect his. “Schedule reviews on a regular basis as a tool for communication and review of risks. Otherwise unpleasant surprises are in your future.” (Turk, 2006, p2)

Strategies for Communication Risks.

1.      Ensure that methods of communication are accessible by all. Don’t put out documents that cannot be read by software that is not available to all. Convert to PDF if in doubt.

2.      For critical elements, physically verify that all that needed to read it did. Use automatic email return receipts or contact the individual personally to verify receipt.

3.      Schedule regular meetings and invite the people that are affected. Track attendees attendance so that gaps can be identified.

4.      Continue to ask who might be affected by a development and contact them.

Conclusion

Resources have to be identified before they are required and then obtained as needed. Obtaining of resources has to be considered for its difficulty, as knowing the need is only half of the equation. Without resources to fill the spaces, the project will not exist.

Understanding what a user may want from a piece of software and the environment it will be used in is an art form. To be able to turn a want into a finished product requires experience and intelligence. Failure in this area will run the risk of destroying the whole project after many hours have been spent. Who does not remember the Sinclair C5?

Unproven Technology can cost. There is a reason Test Pilots exist for no one would want to board a plane that hadn’t been tested but accidents still occur. To develop software that uses Unproven Technology is a risk that is great and should only be used if the current technology cannot meet the requirements of the users. Even NASA is returning to older rocket technology to replace the Space Shuttle.

People are impacted by developments they are not aware of happening elsewhere. PM’s should make every attempt to identify and reach others who may be affected or may affect them during their project. The Ostrich approach of the head in the sand is strictly not a PM method.

As has been seen, the Project Manager of a software development project has significant Risks to consider if he is determined to keep his project on schedule. Through experience and expert help, the PM should be able to overcome the obstacles but he or she must be willing to ask others to support them as they progress. Foundation of the whole project will be strong or weak depending on decisions made early on by the PM. Unfortunately any cracks in the foundation are only likely to appear late, at a time when fixing them will be more costly than desired.

 

References

  1. David Geer, (Jan 2006), Measuring Project Risk, Computerworld, USA.
  2. United States Government Accountability Office (GAO), (March 2006), Financial Management Systems, Additional Efforts Needed to Address Key Causes of Modernization Failures, USA.
  3. Wayne Turk, (Feb 2006), Seven Deadly Sins Of Project Management, Defense AT & L, USA.