Library columns
Pro Developer - Throwing Money Out the Window
Credibility
So, the next time you speak up questioning the path of the new project, don't be surprised that your recommendations and concerns are summarily dismissed. You have a history of failed projects. You have no credibility.
With that in mind, we must learn how to accumulate this rare and valuable commodity, for programmers are not as helpless as the description I've given would seem to indicate. At least, they don't have to be. First, let's look at the benefits that we bring to the party. If programmers ran the farm, the company would benefit by having better functionality, higher quality, improved integration, dependable timelines and the completed projects would actually be used and produce benefits.
By bringing benefit to the company you work for, the project will also make your management look good, thus improving their chances to get what they personally want. And even though nobody cares what your personal desires are, there are at least two people who care about your management's private agenda: them and you.
This is a critical point to comprehend. Programmers have wasted enough breath
in logical arguments to provide the world with wind generated electricity for
the next century. The reason it's a waste of time is that it's the wrong battle
to fight. The decision makers above you are going to make their choices based
on their own agenda. If you take the time and effort to understand their needs
and then learn how to help them achieve them, you're halfway home. Make sure
that they know you're responsible for helping them attain their desires, and
you become something very powerful in the business world: a person with credibility.
Design Specification Extreme Pro
Project management is a sophisticated science. A new emerging discipline in software engineer called Project Management Principle (PMP body of Knowledge) takes systematical approach to solving some of the common problems associated with software failure.
In reading the article I reflected on some of the PMP principles such as scope, stakeholder buyoff, activity planning, and risk management. The flow of PMP is to complex to demostrate in this response but definately most software fails because of lack of planning and design.
I used the PMP model while working as an outsourcing SPA. I found it took 95 percent design and planning and 5 percent code to complete the project. Software development is that political. The technical risks rarely inhibited the release of a program. Object orient technologies and database technologies are extremely flexible.
The real challenge is to bring the business model into focus: business requirements, assumptions, constraints, required resource, and scope (budget, time, resource). The PMP way advocates increased CMM levels to achieve its objectives.
Let say extreme programming principles can fit inside a PMP framework. The PMP framework is designed to produce documentation that brings the business teams into focus and scope. Deliver a product with exactly the desired features wanted, no more no less.
In short, I sympathize with the authors fustrations, but a more beautiful design exists to reduce lose and fustration. Management incompetence is an enemy, but systematic approaches can reduce risk of failure. Let the failure occur on paper first. Using PMP, I had a few project halted because it didn't fit the business needs. The cost was minimal because it was a documentation cost. I recommend, One analysis handling manage numerous development projects, flexibility and cooperation among the team members, and customer center methodologies. Resource matrixes provide availability schedules and extreme programming principles ensure reliability and reuse. Consider this as an approach to reduce fustration.