TECH NOTES

Quality project management is all about the quality of one’s leadership and not their management abilities. Anyone can “push paper” but to not only get a task accomplished but done in an efficient and artful manner takes leadership capabilities which are often missing in business institutions.

Critical to the project management of a software development endeavor is having “a plan”; not a generic one that is easy to fall back on but a unique plan for each and every project that you may take on as a technical manager. This is because each and every project is a unique endeavor with a different known set of variables. Even if the scope of the project as well as the requirements to projects that you have recently accomplished, the factors making up this new project will be quite different if for nothing else than the time period in which it is being worked upon. Things are always changing in a business organization and any given period of time within it has its own unique set of environmental factors which can affect project development quite seriously.

Project estimation, is NOT the “black art” is has been made out to be by many people observing the process. Project estimation if done properly can be quite scientific in process and as a result has nothing to do with the “gut feelings” of a manager who is simply trying to promote him or herself.

Kris Hansen’s piece below introduces you to the many factors in this part of the project development process. And it is the most critical part of the entire process as it forms the basis of the long term plan should lead your effort to a successful conclusion.

(more…)

Mike Kavis, an enterprise architect, has been in the field long enough to experience the uncomfortable fact that project management is the primary factor that leads to most project failure.

Its not just the big projects that fail but the small and medium-sized ones as well, though these smaller endeavors usually somehow make it into production regularly but with a slew of quality issues and poorly developed code. It used to be that a technical professional’s coding style was his or her signature of quality. Today though, with all the capabilities that modern IDEs offer, present day technicians seem to be able to consistently mangle, and badly, what should be a sign of the “craft” and not the “science” as most code appears to be an unintelligible maze of what could only be called some level of illiteracy.

Mike’s piece below details some of the larger mistakes that management makes which over-simplifies his case. Software engineering analysts have found over a 30+ year period of research that project management (or the lack thereof) has been found consistently to be the critical catalyst to all such failure but more a result of not understanding the smaller factors involved instead of the big ones. In fact, approximately 32 separate factors have been identified as the root causes and\or contributing factors in this same time period, all of which can be found in Steven McConnell’s 1996 classic, “Rapid Application Development”.

It should be noted that project failure does not necessarily mean that a production implementation did not occur but that such implementations are simply riddled with defects, poor usability, lack of flexibility, and maintenance difficulties.

Unfortunately, most project management in Information Technology is guided more by personal agenda, irrational business requirements, and political considerations than the quality standards and methodologies that software engineers have shown repetitively over the years that produce superior results within given budgets.

(more…)

For those technicians and technical managers that have studied the methodologies that are the foundations of quality software engineering, they like I, have been most likely very surprised to find so much animosity by their own managers towards the idea of implementing such techniques in their own IT organizations.

Unfortunately, for those of us that are ardent supporters of such concepts, software engineering is more about cultural adaptation than technique. The techniques have been refined over 30+ years by highly competent technicians, analysts, and technical managers, all who have provided quality results on time while saving their organizations huge sums of monies. You would think that such success would be enough to convince even the most persistent naysayers to opt for some consideration of this approach towards software development. The reality is though, it never has and most likely never will.

It was the United States that developed the software industry into what it is today; and for the most part we can take the blame for all of its failings… and there are many. However, the most egregious act against our profession has been that massively, incompetent business management has created a culture off subservience by IT professionals instead of one of equality while commoditizing a scientific discipline into nothing more than the equivalent of a store-bought toaster. This has always been the most difficult aspect for most people in business, no matter what their job or career title may be, to deal with; that most managers are complete failures at their jobs. That incompetence is embedded in the culture of business which is solely based upon the “greed factor” which has overtaken American corporations beyond what it was after American industrial dominance began to rise after World War II. Back then, companies were not huge institutions for the most part and those that led them had vested interests in making sure they ran with a modicum of stability and success.

With the advent of “professional management” all that was lost as they increasingly viewed only profit as their sole reason for existing. Anyone who would like to dispute this is welcome to read Joel Bakan’s (a noted Canadian jurist) excellent treatise on corporate sociology, “The Corporation”.

Once installed, any hope of refining the Information Technology field into a truly professional career discipline was lost along with it.

(more…)

Most technical managers in IT still do not know how to go about defining a rational time estimate for a software development project. And yet, over 30 years of continuous research by software engineering analysts has consistently proven that by applying software engineering principals, standards, and methodologies, technical managers would be able to meet their project deadlines more consistently with lower defect rates, higher productivity, and higher morale among their staff.

So the question is then, “Why do so many managers insist upon using “wishful thinking” and\or bullying to get their projects through the development process?” Simply put, most managers are under severe time constraints by their own management in the business units and instead of learning the skills that would allow them to more successfully handle such pressures they instead use such constraints as an excuse to avoid the effort required.

Just as importantly, software development is an engineering discipline which requires precise approaches to its successful implementation and application. However, with the current fad that all technology is merely a commodity to accomplish a task, there is little incentive for technical managers to actually take the initiative to attempt the implementation of processes that would allow their projects to be handled in such a way.

To get a better understanding of the critical nature of software development and its requirements we can begin with an excellent piece from Construx Software that explains the uncertainty inherent in all software projects and if not accounted for from the beginning will most certainly make itself felt during the process.

Written by Stephen McConnell, a leading software engineering analyst, the concept of a “cone of uncertainty” is based upon years of research of software project failure by leading software engineering analysts. To date, there hasn’t been a single book or theory that has been able to refute any of the standards and methodologies in the software engineering process.

Once you complete reading of Steven McConnell’s piece you will understand why companies waste so much money on mediocre and failed project development.

By the way, I highly recommend the following books, both of them written by Steven McConnell:

Software Estimation: Demystifying the Black Art

Rapid Development: Taming Wild Software Schedules

Steve
Black Falcon Software, Inc.

(more…)

“Six Sigma”, the engineering tool used to rein in financial costs while improving related processes, is, as reported in the BusinessWeek article below, experiencing a decrease in interest by corporate management. Though not normally associated with software engineering processes, it tends to be in large companies the receptacle for which such metric-based data is used to calculate costs and their associated benefits… or lack of.

Nonetheless, management cadres that have been using this once highly popular process improvement methodology are beginning to report that its strict concentration on the financial aspects of a corporation are beginning to cause more harm than good to the innovative side of things.

However, to be honest, there is no large company any place that can be considered “innovative” by any stretch of the imagination beyond their advertising and except, of course, in the imaginations of those who are running things. For example, it has come to light by pharmaceutical analysts that there hasn’t been a single truly “innovative” drug produced by the US drug industry in two decades.
(more…)