Regulatory impact assessment (RIA) is widely adopted as a global practice when developing new legislation and regulation. The RIA is all about what should happen. Project management is all about what does happen. Understanding RIA can benefit project managers who are enlisted to successfully realize the RIA recommendations.
Software development projects have a poor record of success. Half finish over budget, nearly two-thirds are deemed failures by the initiating organization, and nine out of 10 exceed their deadlines (see “Managing Complexity” from The Economist, November 25, 2004).
Even if your projects haven’t fallen into any of these categories yet, it might be prudent to arm yourself with a few tried and true techniques to stave off disaster. This article will revisit seven of the most common causes for project failure, consider their solutions and provide some techniques you might have missed such as developing an ERD from Day One, and driving the user interface based on the structure of your data.
A Well-Known Solution
For the last 30 years, software development methodologies have been available to guide projects so they will consistently deliver high quality applications on time and within budget. Experienced project managers love them, but for various reasons don’t always use them.
Amol Kaikini, a project manager and fan of formal methodologies “since Reagan was in the White House,” has obtained remarkable success with them. As long ago as the early 1980s, his department used the Warnier/Orr methodology (also known as Data Structure Systems Development or DSSD). The result? “We always delivered on time, with very few defects, with reliable code too.”
Eric Nelson, a project manager and consultant of 10 years, takes it a step further. “If projects adhere to a methodology and [the managers] don’t take any shortcuts, then they will succeed 100 percent of the time.”
With strong claims of success like this, why doesn’t everyone just pick up a methodology and start succeeding? Why do projects continue to fail 30 years after a failsafe was invented?
Problem No. 1: An Unknown Known or a Known Known?
Kaikini attributes it largely to a lack of awareness about formal process. In his experience, many younger project managers either don’t know that methodologies exist, or don’t understand their potential. “Schools don’t teach method, or even design for that matter,” says Kaikini. “And for those that do, the courses aren’t required.”
Nelson, who learned of methods and formal design 12 years ago in college, doesn’t necessarily agree. “There’s actually a ‘software development methodology’ class at University of Virginia,” he says, but while the class is required for all computer science majors there, it may be one of the few in the nation with such a requirement.
Another sticking point appears to be that many project managers know of methodologies, but for various reasons don’t use them. Nelson admits he’s one. He blames project stakeholders.
Problem No. 2: Managing Management
A major problem facing projects managers in the IT industry is obtaining stakeholder buy-in to the use of formal process. Don Webber, who has been involved with about 80 projects since the mid-1980s, summarizes the typical stakeholder aversion to the use of methodologies: “Business management’s concern is budget and timeline…they don’t really care about the approach.”
Consulting companies have an especially difficult time. Customers look at an estimate with a big number at the end broken down by phase and start cutting: “Requirements gathering? ‘Optional.’ Design? ‘Here are your screenshots.’ Quality assurance? ‘Our end users can test’. This happens with just about every client I’ve ever worked with,” explains Nelson. And that’s the beginning of the end for that 100 percent success rate.
So what can a project manager do? Having customers cut or reassign parts of a project may not ruin the project, but stakeholders must be made aware they increase risk of failure. To do this right you must spell out the risks in formal, written documentation such as a project management plan. If you can find the time you should prepare mitigation strategies as well.
Problem No. 3: Plan for Planning
While some methodologies, most notably the Rational Unified Process, explicitly include time for planning, many others, most notably Waterfall, don’t. Of course as a project manager you know to include time for project initiation, planning and identifying stakeholders, risks, quality standards, acceptance criteria and so on.
Don Webber identifies lack of planning as a major contributor to the failure of many development projects. “You just don’t see planning or ending on typical projects” says Webber, who recommends spending at least a week of dedicated initiating and planning time plus additional time for formal acceptance of the delivered application.
Problem No. 4: Communications
Initiating, planning, designing and closing all have communication in common. And Webber rates the lack of it as the No. 1 reason that projects fail. He recommends project managers document in writing the project management approach, the initial requirements (agile methodologies would of course refine those requirements later) and the design. The goal is the same: make sure all parties understand what will be delivered and how it will be delivered.
But what if an implementer’s pre-development understanding of user’s needs still doesn’t match their needs at the end of the project? It’s a common problem and one that is addressed differently by different methodologies.
The popular waterfall methodology doesn’t account for it at all. That’s why it can be risky to use on medium and large projects.
The Rapid Application Development (RAD) methodology uses a combination of Computer Aided Software Engineering (CASE) tools, prototypes and iterative development to put a scaled down but working application in front of the client as quickly as possible.
Agile methodologies such as eXtreme Programming (XP) drastically shorten requirements gathering and design and shorten the iterative development to days or weeks, but have the same goal: show the client results as quickly and get feedback as possible so as not to waste time going down a path the client didn’t intend.
The Just-In-Time Application Generation (JAG) methodology, proposed by Automated Architecture Inc, takes a more RAD approach by requiring implementers to design the database early and use CASE-like tools to generate working applications in the design stage, prior to development.
Amol Kaikini is a fan of the latter approach: The power comes, he says, “When you create that data model and generate that code, and you walk [users] through the use case, and they’re like, ‘No that’s not how it should be.’ Each comment saves you probably three FTE [full time employee] months, and I’m not joking.”
Three FTE months may sound like a lot, especially if you are used to smaller projects, but the point comes across loud and clear: miscommunication can be expensive.
Problem No. 5: Lack of Design
One problem unique to software development projects, and along the same lines as communication, is that most methodologies require designing before building; and developer’s frequently just don’t see the benefit. “Methodologies are everything that isn’t fun about developing,” explains Nelson. Design can appear to be just one more thing to slow a developer down from getting the job done, he says.
Doug Kinney is a developer in the IT department of a large 2,000 employee security services company. His projects are a perfect example. According to Kinney, “We’re so swamped, we have so few resources…[at some point] you’ve just got to get stuff done.” This is one reason his projects hardly incorporate design: there just isn’t time.
So what’s so important about design? The consequences come when you get it wrong, and the larger the project, the worse the consequences can become. Just putting together a few screenshots is insufficient for all but the smallest of projects. Large and medium projects can benefit from the use of use case diagrams, process diagrams, activity or state diagrams, and more. However, all projects can benefit from Entity Relationship Diagrams (ERD), and they’re so important they deserve their own section:
Problem No. 6: Circle and Line’s: Child’s Play or Lifetime Proficiency?
It seems like a dying art, but the ability to create a correct Entity Relationship Diagram is so important for a software development project that every IT project manager should know how to read and write ERDs without thinking.
Why? Because every software development project has a database or some kind of data structure, and that data structure provides the foundation of the entire project, and a change to the relationships in that foundation during development can be “pretty severe,” according to Nelson.
Beyond that, it’s a technique to improve communication, find answers to questions that developers will ask and jump start database design without worrying about pesky details such as primary and foreign keys, database fields and indexes. You can leave most of those details to a Database Administrator (DBA).
Not sold yet? The ERD can also serve as an effective metric. On a recent project, a customer joked “You charge us $10,000 every time you draw a circle, don’t you?” The funny thing is he was right. ERD diagrams can--and should--provide a metric to estimate project size. Large projects developed by hand can cost up to 120 hours of development for each entity in the ERD (excluding the associative tables that resolve many-to-many relationships and lookup tables such as employee type).
How many hours of development did you spend on your last project? How many entities did it contain? You might be surprised to learn it costs a lot more to draw a circle than you thought.
Technique No. 1: Getting the ERD Right
The best approach is to start from day one of the project with a piece of paper dedicated to drawing your ERD. Keep it with you at all times, and write down every noun you hear from the customer. Circle the nouns and draw lines between them as you discover the relationships. The trick is remembering which “crow’s feet” go on which side, and it is vital to get it right. The following diagram quickly summarizes this:
Figure 1 Understanding an Entity Relationship Diagram
The difficult part may be identifying areas for which customers don’t have a word or when one word can represent multiple entities. Agreeing on a vocabulary is a vital part of getting communication right on a project.
After a day or two of informal meetings, you should have most of the entities and a pretty good feel for how they relate and are ready for the ERD facilitated session. Get a whiteboard and talk the client through each entity in the ERD and describe both the cardinality (multiple-ness of the relationship) as well as the optionality (the zero-ness of the relationship). It may take more than one session to get everything right.
Problem No. 7: Scope Creep
Of course as project managers we all know about the risks of gradually increasing scope. It’s more of a problem with traditional methodologies than agile ones, but regardless, one of the benefits of the above technique is it can help draw these issues out prior to development.
At some point during the ERD facilitated session you’re bound to hear: “Well, most of the time it’s this way.” Be careful. Less experienced project managers may be inclined to draw their ERD based on how the business is rather than how the application will be and unwittingly expand the scope of the project.
These statements typically show themselves with many-to-many relationships, which can require a great deal more development effort than you realize. It may be worth tabling the issue and running it by a developer.
If it looks like a lot of effort, remember: iterations. It might make more sense to move the feature into a future release. Delivering an application sooner that encompasses 80 percent of users needs might just be more valuable than delivering an application later that encompasses 95 percent of needs.
What’s next depends on your methodology and the plan you developed up front. You’ll need to add fields to your ERD, probably in another facilitated meeting. You’ll then generate the database from the model. You may want to provide mockups, and if so remember you should base them on your data structure more than your requirements in order to minimize development effort. If you use a RAD-like methodology, you’ll work on a prototype.
If you follow a variant of the JAG methodology, you may find that generating a working application augmented with mockups of custom functionality is extremely beneficial for both immediately receiving feedback from users on your design and jumpstarting development.
The trick is finding a good generation tool with a low learning curve. Beware of Model Driven Architecture applications based on specific, customized or obscure flavors of the Unified Modeling Language (UML). The search may be worth the effort.
Software development projects are a risky business, and the odds are clearly weighted against your success. However, with appropriate planning, communication and design strategies--and some handy techniques like the ERD--you can drastically increase your chance of beating the odds.
Lee Richardson is a veteran of more than nine years in the custom application development and code generation industries. Lee is the founder of Automated Architecture, Inc, and is the author of Blue Ink, a tool for rapid application development.
Want more content like this?
Sign up below to access other content on ProjectManagement.com
Already Signed up? Login here.