Use of an inappropriate methodology. While the raging debate about methodologies assumes that one methodology is inherently superior, such judgments are unwarranted without consideration of the project context in which the methodology is applied. It is not the chosen methodology per se that drives project risk but how well it fits a given project. All development methodologies agile, lightweight, spiral, or structured encapsulate some approach for embodying customer needs in the features and functionality provided by a system. For example, a methodology such as rapid prototyping relies on iteration to uncover novel or poorly understood user needs. In contrast, a structured methodology emphasizes structure over iteration and might be more useful for managing larger projects where requirements are better understood. A "one-methodology-fits-all" mentality can lead to uneducated choices that can raise rather than lower project risk. While better tools or heuristics are needed to help project managers assess project-methodology fit, it is perhaps easiest to think of fit as lack of misfit between the chosen methodology and what it must accomplish. A well-fitting development methodology can also help cope with other risk drivers such as project complexity and requirements volatility. This surprising finding clearly calls for more research attention in the software development community.

Translation - Chosing to do a project under JAD that has low customer involvement will make for a lot of wasted meeting time, just as chosing to do one that has constantly changing requirements under the waterfall model will make for a poor product.

Notes - All this assumes that some formal developemnt process is chosen and articulated. This is generally part of a formal project management procedure, which is the third most important issue identified in the paper. In this way, Tiwana & Keil's study seems to put the cart before the horse, and is one of the reasons why many feel it doesn't identify the real factors that make projects succeed or fail. Again, I must stress that while this study may not show the way the world really works, it is shows how the world is percievecd to work by those in charge. As such, it is useful to those of us who have to deal with them. And that its ... well, pretty much everybody.

Lack of customer involvement. The second most important driver of project risk customer involvement is an inexpensive but underused form of project insurance. Project requirements are derived from expressed or inferred customer needs. The accuracy with which these needs are understood determines how well the intermediate artifacts of the development process, such as requirements documents, specifications, features, and code, embody them. The problem is that customers often know more than they can tell: Their understanding of their own needs is "sticky" or difficult to articulate. This creates the classic chicken-and-egg problem: A system cannot be built without requirements, and requirements cannot be fully elicited until a rudimentary system can be seen. Some approaches for involving customers in the development process include customer walkthroughs, prototypes, use cases, pilots, and user reviews. Feedback and ideas for refinement from involved customers can clear up misunderstandings and help align developers' and customers' visualizations of the system. Moreover, involved customers are likely to be more receptive to the project's outcomes, which lowers the risk of late-stage rejection.

Translation - Customers often don't know what they want until they see what they are going to get. Keeping them in the loop during the design and developement processes makes for a better product and gets them to "buy-in" to the final outcome of the project.

Notes - This is the whole reason JAD is so popular. The paper fails to identify other "stakeholders" that will have something to say about the project. For example, the Sales Department may want to have the project produce a product that it can sell to others, or some major player in the company may be resistant to the project because it reduces his sphere of influence. A properly-run JAD methodology can help mitigate these other forces of influence and even turn them toward project success.

There is something just a little immoral about getting people to "buy-in" on a project outcome by making them feel engaged during its development process. Running JAD just to make people feel better about the inevitable outcome assumes that you're smarter than the are. And if you're so smart, why ain't you rich? Besides, JAD works, and you can't argue with success. Well, you can, but you look like a fool doing it. Fools aren't smart.

Lack of formal project management practices. The third driver of project risk is the extent to which formal project management practices such as formal plans, schedules, budgets, and milestones are used. Some would still argue today that software development projects are fundamentally "different" from other types of projects and that formal project management practices somehow don't apply. Our findings strongly suggest otherwise, implying that formal project management practices have the power to reduce software project risk. The value of such practices lies largely in the well-defined patterns and directives that they create for coordinating interactions and integrating inputs from various project constituents. Formal milestones also help in monitoring progress and spotting discrepancies throughout the project trajectory.

Translation - Formal project management is important, if for no other reason than it keeps people informed about the project's status and lets them help when they need to.

Notes - Publishing project status based on a pre-established benchmark that may or may not be an accurate guage of true project performance seems like a double-edged sword to most people. Many feel that reporting to anyone who will listen that their project is behind schedule and/or over budget is a bad thing, but it has two nice advantages. People prefer honesty and will appreciate the fact that you've given them a heads-up that the project is headed down the tubes and an opportunity to help save it. Plus, if it does fail, you can always say "I told you this would happen!" Prophets are very highly paid and generally do less work.

Dissimilarity to previous projects. The fourth driver of risk is a project's similarity to ones that have previously been completed in an organization. If a new project resembles previous projects, a company is likely to be familiar not just with the hardware, software, operating systems, programming languages, and application domain, but also with their constraints and the problems that might unexpectedly occur. Tried-and-tested heuristics, estimation models, design rationales, project plans, problem-solving approaches, and even code from previous projects can be readily repurposed. The more a new project differs technically and conceptually from previous projects in an organization, the greater its exposure to risk.

Translation - Doing projects like ones you've done before lets you use tools and knowledge you already have.

Notes - This is an aversion to learning curves. Learning curves, if properly managed, are good things, because they bring new skill sets and products into the company's fold. Learning curves are percieved as bad things, though, because they take time and let employees pad their resumés. Hide learning curves whenever possible, or cast them as "If we don't do this, XYZ Corp. will eat our lunch." Find ways to give employees a week or two bewtween projects for training, and make it sound like a curse; busy-work to cover a scheduling gap, continuing education, standards compliance, whatever.

Project complexity. Project complexity emerged as the second lowest of the six drivers of project risk in our study. A project can involve both technical and organizational complexity. Technical complexity stems, in part, from a system having to interact with a large number of other applications, interdependencies, and the complexity of the interfaces to other systems. Technical complexity raises the difficulty of estimating the resources that must be allocated to a project, exposing the project to feasibility, budget, and scheduling risks. Organizational complexity grows with the number of departments or organizations involved in and affected by the system. Organizational complexity raises coordination challenges and exposes the development process to unpredictable coordination failure. However, software project managers tend to accept complexity as a known driver of project risk over which they exercise little influence, which may explain its relatively low weighting in relation to other drivers of project risk.

Translation - The more stuff and/or people are involved in a project, the more likely it is to fail. Managers often think there is little they can do about this.

Notes - Well, DUH. But actually not. Big projects have big visibility, and provided you keep people up to speed on their status (see formal project management above), companies will throw tons of money at them to keep them on track. When big projects look like they might tank, you'll be amazed what you can get to help you get them back on track.

Complexity doesn't play well during the project approval process, though. Hiding complexity rarely works, managers aren't stupid when it comes to managerial stuff. They'll see right through your claims that "we can handle it because we've got bright people," or any attempt to minimize the impact the project will have on corporate resources. Paraphrasing an old saw, "if you can't baffle them with bullshit, dazzle them with brilliance." Invent new technologies that they no little or nothing about that will magic-away the project's complexity. Lack of knowledge beats a sneaking suspicion every time. How do you think workgroup collaboration software got started?

Requirements volatility. Project requirements define the mapping between customer needs and the functionality provided by a system. Building a system on volatile requirements is like attempting to build a structure on a foundation of sand. Tweaking an unfinished system to match shifting requirements requires additional programming effort and expensive reworking. Even if requirements are correctly elicited, there is no guarantee that they will remain unchanged over the project trajectory. Both changing business environments and fickle customers can contribute to requirements volatility. A certain level of requirements volatility has come to be expected in software projects, which may explain why this factor emerged with the lowest weighting among the six drivers of project risk in our study.

Translation - The project is defined to meet the customers needs. Changing those needs during the project can result in a lot of extra work. Often, this can't be helped, though, and should be expected.

Notes - Ah, feature creep. Programmers probably hate this above all the other slings and arrows they endure, yet it rates lowest on IT managers' list of project killers. JAD can help hold down on this, but it will happen, count on it. Impress on your superiors the need for direct access to the customer by the developer and vice versa.