On VB
Failure's Secret Sauce: Poor Project Management
On VB columnist Joe Kunk says coding errors can lead to trouble, but the vast majority of big mistakes are due to poor or misguided project management.
Recently I wrote a column titled "
My Biggest VB Programming Mistakes
." I am afraid that I told only a small part of the story when it comes to failed software projects. While technical errors do occur and can be significant, my experience over 30 years is that the root cause of most distressed or failed software projects is overwhelmingly due to poor or missing project management practices. Developer mistakes are relatively easy to remedy compared to poor planning, a lack of leadership, bad estimates or the impact of unanticipated risks.
Consider the developer that spends weeks furiously coding an "urgent" feature, only to find out that management was still evaluating the request and has just declined to approve it. Or the developer that carefully crafts the perfect algorithm, only to find out that it is incompatible with critical requirements that the user failed to mention. Or the client’s insistence on completing a comprehensive test cycle that was not budgeted or scheduled in the quote. Or the disruption of a failed "big bang" implementation that leaves critical systems down for weeks or even months as the bugs are worked out. These are failures in communication, requirements specification, project scope and risk management, respectively.
I suspect that many developers see project management as nothing more than an impediment to their creative expression and wish they could focus purely on the code day in and day out. The reality is that project management can’t go away; business process owners still need to be concerned about budget, schedule, cost, and risk.
I am not a certified project manager. I look at project management from the perspective of an experienced developer. So what does "project management" mean in today’s world?
Project management provides important business value by addressing the Project Management Concerns questions in the list below. As you can see, they do not specifically address how the software will be built, but instead address the why, who, what, where and when of software systems. That is an important distinction; software development practices address the HOW and project management addresses the remaining questions.
Project Management Concerns
- What does the user want and why? What are the scope, benefits, costs, and priority? Should it move forward?
- Have all the important factors been considered before decisions are made and costly action is taken?
- What is the best architecture and design that meet the users’ needs? What will it cost and how long will it take to deliver a particular set of desired features?
- Ensure project risks will not derail the project. If something does go wrong, what did and why?
- What staff and technical resources are needed for the project so they can be properly scheduled and funded?
- How will it be demonstrated that the features are implemented as agreed without bugs?
- How will the system be implemented and any existing data migrated?
- What support will be required to keep it functional and useful? Backups? Network?
- How will users be trained in its use?
The general phases of a software project are Initiation, System Concept, Planning, Analysis, Design, Construction, Integration/Testing, Implementation/Deployment, Post Implementation, Maintenance/Support, and Retirement. Some phases may be reduced or skipped based on project size, risk and corporate culture, but they must be considered at some level for each project.
I began my career when the define-everything-up-front approach of the Waterfall model was generally accepted as the best way to minimize risk. Coding, testing and implementation was predictable if everything was documented before the coding started. Experience has shown that this model fails in an environment where requirements change faster than the ability to deliver fully pre-planned systems.
Younger professionals may find it difficult to understand why the waterfall model was so widely accepted. It becomes clear when you understand that the computer world was very different in the 1970s and 1980s. Most business systems ran on mainframes where each program performed a very narrow function and interactive terminals were rare. Inputs/outputs consisted of magnetic tapes with specific, fixed-field record formats, a "process" typically required multiple batch programs, and careful planning was required to make sure everything integrated at deployment. Software was much simpler and business requirements changed much more slowly than they do now in the Internet age.
Lightweight iterative agile development practices like the popular Scrum methodology methodology have been developed to work more closely with customers to deliver the highest value features in quick iterations that provide deliverable artifacts at the end of each iteration.
These two models appear very different. Most of my experience has been with some variation of the waterfall model. I can’t offer any hard numbers on the percentage of organizations that still follow the waterfall development model, but I know that I still see a lot of organizations that do, just the developers are often reluctant to admit it.
What do I consider the best software project model today? Small projects may work well with a pure agile approach but my experience is that most Information System departments suffer from significant backlog, ongoing legacy software maintenance, budget and staffing constraints, and specialized skillsets. In this environment I recommend a hybrid approach where the project phases of Initiation, System Concept and Planning are completed at a high level to provide an overall skeleton of budget, staffing and schedule estimates for project approval. Then software construction should be performed within those constraints in an agile model to deliver the best value to the customer as quickly as possible.
Should developers be concerned with project management?
The Project Management Concerns I listed above are very important and must be addressed in any non-trivial project. If project management is so fraught with dangers, should the developer stay safe by focusing the technical requirements and leave project management to others? Absolutely not. The best developers I have known also have a keen interest in gaining good project management skills and applying them as they work. Like programming skills, good project management skills require dedication to learn and constant refinement; perhaps even more so.
What has been your experience? How has project management, good or bad, impacted your development efforts? What works best for you for what size or type of projects? Let me know in the comments section below.
About the Author
Joe Kunk is a Microsoft MVP in Visual Basic, three-time president of the Greater Lansing User Group for .NET, and developer for Dart Container Corporation of Mason, Michigan. He's been developing software for over 30 years and has worked in the education, government, financial and manufacturing industries. Kunk's co-authored the book "Professional DevExpress ASP.NET Controls" (Wrox Programmer to Programmer, 2009). He can be reached via email at joekunk@ajboggs.com.