The remaining factors out of the Standish top 10 list are of lesser importance to success, but nevertheless are worthy of a brief comment.
10.3.1 Agile Development Approaches
There is a growing school of thought among IT system development technicians that requirements cannot be adequately defined at the outset; therefore they espouse an alternative requirements definition strategy. That is, quickly formulate a basic plan and then proceed to develop a series of small iterative solutions that the user can evaluate. In this fashion, the project would be executed by managing creation of these “chunks” of capability. This methodology school of thought is most often called Agile or Extreme (among other names). In using this approach, the user would work closely with the tech- nical team to produce quick and small instances (chunks) of the solution. In some cases, these would be called iterative prototypes. The goal of this approach is to quickly gener- ate user value and to quickly validate requirements. One clear advantage of the iterative methodology is that project deliverables are seen by the user earlier than would be found in the traditional “bigbang” serial life cycle implementation approach. Conversely, some would argue that this could cause extensive rework and therefore additional cost. Scope of this discussion does not allow us more time to wrestle with these advantages and disadvantages, but the contemporary PM should be versed in both approaches and cus- tomizes his project to fit the situation.
Regardless of one’s conceptual development methodology model, there is general agreement that defining accurate requirements is fundamental. Evidence confirms that some level of early definition of the business objective is needed. From that point, either the iterative or the traditional JAD (or both together) approach could be pursued effectively to serve the requirements definition role. Cartoons similar to the one shown in Figure 10.2 have draped walls in almost every system analyst area. When first see- ing this example, people laugh. After being in the job of a few years, all understand its meaning. Communicating accurate requirements is hard work and often not done well. This classic cartoon describes a not too far out scenario showing how requirements get garbled through the organizational layers.
Manageable Low Low High High Complexity Scope Challenge d High risk
10.3.2 Existence of a Standard Process Infrastructure
This item implies that each project should not have to reinvent the organizational pro- cess environment. By utilizing standard processes, the new project can simply plug into a defined and well-managed foundation without having to deal with reinvention of equivalent supporting functions. Too often, a new project will have to create its own tools and processes that have to be engineered as part of the project work. These sup- port tasks are essentially nonproductive to the end requirement and yet consume valu- able resources to produce. If excessive, such activity will negatively impact the project capability to deliver. Use of standard management components and processes should be stressed wherever possible for this reason. When new tools and technologies are chosen, recognize the added risk created by the creation of these untested items.
10.3.3 Use of a Standard Methodology
Previous discussion has described the role and structure of a methodology. If properly applied, this form of standardization can be productive because of the underlying pro- cesses that are familiar to the various stakeholders. From past efforts the methodology should have been tested and the result will be usable components such as templates, operational processes, lessons learned, and a common vocabulary. There is research evidence from William Ibbs and others that organizational maturity has a positive impact on project success (Ibbs and Kwak, 2000). The sensitive issue here is to ensure that the methodology is flexible enough to handle different project types and sizes. One approach does not fit all situations. The issue of increased risk management has come up in other discussions. In this case, the risk element is that management oversight and documentation specified in a methodology will in effect sabotage team productivity. More control and oversight should be applied to larger and mission critical projects; less for smaller and noncritical projects. One size methodology is not the correct approach. Project teams left to their own devices often choose to do little documentation or sta- tus communication. Obviously, this is not a desirable outcome for most efforts, so it is
User Requirements?
As proposed by the
project sponsor As specified in theproject request As designed by theengineer
As produced by
manufacturing As installed at theuser’s site What the user wanted
Project Initiation • 105
necessary to think through the control and management activities for each effort and obtain agreement regarding how much is appropriate and then specify this as part of the formal project plan.
10.3.4 Reliable Time Estimates
There are many contributing issues that can lead to false expectations from the stake- holders. When schedule, budget, or technical estimates are bad, the project is often viewed as a failure regardless of other factors. Basically, the original project estimates influenced the decision process to approve the project and they create associated user expectations. If one or more of these estimates is flawed, there may be a significant impact on the value of the project. Sometimes, estimating errors are the result of inad- equate requirements definition, whereas in other cases, it is the result of inadequate skills or erroneous assumptions. Simply stated, a bad estimate yields a bad result in the stakeholder’s eyes.
10.3.5 Availability of Appropriate Skills
Failure to provide timely quantities of skilled resources is an important and visible attri- bute for project success. Note that this obviously critical item is last on the top 10 list likely means that it is widely recognized and already focused on as part of project man- agement. It surely does not mean that it is number 10 in importance. Every manager rec- ognizes that skill levels are variable across different workers, so their impact of budget and schedule are clear in this regard. Also, there may be some aspects of the project that can only be accomplished by a high skilled individual. We will see implications result- ing from skill variability in many future discussions.
10.3.6 Industry and Organizational Culture
Beyond the internal organizational factors described above, there are also various dif- ferences observed by industry and organization. As an example of this, the Standish surveys document that the retail sector experienced the highest project success rate, while government projects tend to exhibit the lowest. Much of this difference in proj- ect performance can be explained by the types and sizes of projects typically pur- sued in these industries. Certainly, the government often pursues projects that are of mega size scale and we have seen that these tend to have less success than other smaller initiatives. Another factor that does not yet appear on the Standish survey is that of individual organizational culture. It is difficult to describe this term, but it basically relates to the internal support environment for the project and the general maturity of the organization. A well-conceived project that is appropriately managed will have a higher probability of success than one that does not have these character- istics. Also, an available pool of appropriately trained resources affects success rates. A third aspect is related to issues inherent in a global organization. For instance, a strong departmental organizational form with a territorial view is not conducive to complex intradepartmental types of projects. There are also other cultural factors that can affect project performance and when initiating a project this class of issues must be recognized in their role of either nurturing the effort or creating roadblocks and constraints. We have used the metaphor previously that a project is like a flower seed planted in a flowerbed. The organization is the flowerbed and if it does not nurture the project seed, it will die. This is the impact that organizational culture contributes to the project and its ultimate success.