April 30, 2007

"THE DICHOTOMY OF SYSTEMS DEVELOPMENT MANAGEMENT"

In order to be a Systems Development Manager, you have to be a lot of things: front man, educator, mentor, sage, politician, etc. Oh yea, something else, you also have to be a hypocrite. In order for you to survive in today's corporate world you have to say one thing to your superiors and staff, but then do something entirely different in practice. Let me give you some examples:

• On the one hand, managers know it is important to do the upfront work in systems design, e.g., current systems analysis, information requirements definition, establish the proper systems architecture, etc., but on the other hand, they encourage their staff to rush to coding without first thinking the problem through. This is because programming is a much more tangible task than systems analysis, thus providing demonstrative evidence to the end-user that the project is progressing. Managers rationalize this by claiming they work in a pressure cooker and, as such, "We don't have time to do it right."

• On the one hand, managers claim they want standardization in their work effort (to get everyone communicating and working on a common level), but on the other hand, standards are thrown out the window the moment push comes to shove.

• On the one hand, managers want interchangeable workers who can easily pick up where another worker leaves off, but on the other hand, they are unwilling to train the workers to a uniform and consistent skill level.

• On the one hand, managers understand the virtues of sharing and reusing information resources, e.g., integrate systems and eliminate duplication, but on the other hand, no mechanism is implemented to check for redundancy. Consequently, systems lack integration, data integrity is questionable at best, and systems are routinely rewritten over and over again, representing redundant work effort.

• On the one hand, managers know their systems and software should be properly documented in order to expedite maintenance and future modifications/improvements, but on the other hand, documentation is one of the first things sacrificed when a project is delayed. It is assumed the system will be documented afterwards; unfortunately, it never is. Instead of documentation being viewed as a vital working tool and a byproduct of design, it is viewed as an inconsequential and burdensome task.

• On the one hand, managers claim they all want quality workmanship, but on the other hand, they are unwilling to impose the required discipline, organization, and accountability to implement a quality environment.

• On the one hand, managers promise to implement projects on time and within budget, but on the other hand, this seldom occurs as project management is superficially implemented in their organizations.

• On the one hand, managers want their systems to be portable, thereby making them independent of their machine environment, but on the other hand they fall prey to the latest technical promise and develop systems tailored to a particular physical device.

THE "PILL" APPROACH

Obviously you cannot have it both ways. You must take a position and implement accordingly. Basically, there are two alternatives: a tool-oriented approach or a management-oriented approach. On the surface, the tool-oriented approach appears to be the least painful as it doesn't require any political maneuvering or management chutzpah. I refer to this as the "pill" approach for problem solving. Let me explain. Years ago, comedian George Carlin talked about how America's drug culture came about. It was his contention that we are taught to pop a pill at an early age such as with children's vitamins. As we get older, it thereby becomes natural for us to pop a pill for whatever woes we experience. It may not be the right treatment, but we believe it is the most expeditious approach for satisfying our problem. Ask any doctor, and they'll tell you placebos can work wonders in certain situations, but they also know they have limitations and are no substitutes for suitable medical treatment.

This "pill" phenomenon is no different than purchasing a new development tool that claims to solve all of your problems. You know what? There is no such tool. It doesn't exist, it is a myth that rates up there with the Easter Bunny and the Tooth Fairy. Nor will it ever exist. The reality is that we will always need a variety of tools that address different aspects of the development process. And understand this, in software alone, there are hundreds of ways to skin a cat; thanks to different programming languages, design and data base techniques, etc. As much as we hate to admit it, systems development can be a lengthy process and anytime we try to short stroke it with the latest tool du jour, we only cause headaches later on. You cannot keep applying Band-Aids when major surgery is required.

On the other hand, there is the management-oriented approach. This requires structure, discipline, and responsibility; three ugly words in today's systems development landscape. But before we tackle anything of substance, it is essential that such an environment be created. Can you imagine designing a bridge or a building without such disciplines in place? Hardly. Why should systems be any different? What is needed is the establishment of a professional attitude among the staff; whereby a system is viewed as a product that can be engineered and manufactured like any other product. Once we have the proper perspective, we can organize the staff accordingly and create a concerted development effort. True, we will use pertinent tools in the development process, but we have to recognize that tools will come and go, and are dynamically applied. It is the process of building systems that should be regarded as a precursor to the application of tools, our methodologies. Only when we can reshape our homogeneous development environment into a homogeneous environment will we be able to act as true professionals. Unfortunately, this requires some management fortitude, something that is in short supply these days. A lot of people, throw up their hands and say this is not possible due to the management realities of today and resign themselves to doing small insignificant applications, hence the dichotomy mentioned earlier.

But let's consider what we have done over the last thirty years. We have tried CASE tools, 4GL's, program generators, prototyping aids, report writers, BPR tools, DBMS packages, programmer workbenches, etc. True, we have some great application development tools, but if they are so good why are we still experiencing problems? The answer is obvious; we have abdicated management control over our systems development environment.

Now is the time for systems development managers to stand up for their departments, their profession, and themselves, and act like managers. All of the things you claim to want and support are within your grasp, as long as you start behaving more like a manager as opposed to a pawn for the latest programming gizmo. Face it, you have been seduced and abandoned by your tool vendors. You can talk the talk, but can you really walk the walk?

CONCLUSION

Managing a systems development environment requires someone skilled in the fundamentals of management, is not intimidated by technology, and has a more global view of systems. Some of the best systems development managers I have met over the years were people who didn't have a computer background, but, instead, came from a user area and were not intimidated by the latest technical gobbledygook. They were pragmatists who were results oriented and implemented a management environment where development terminology and concepts were standardized and consistently applied. Frankly, some of the best candidates for the position of systems development manager, are the sharpest critics of the department. Companies then said, "Okay, put up or shut."

Unfortunately, most of today's development managers are the antithesis of what I have just described. If the choice is between quality and speed, they will always take speed. The point is, you can have both without sacrificing either, it just requires some proficiency in management.

All systems development managers know what the cure is, they are just not willing to take it. But understand this, you cannot have your cake and eat it too.

OUR BRYCE'S LAW OF THE WEEK therefore is... "A Systems Development Manager speaks with a forked tongue."

MY "PET PEEVE OF THE WEEK" IS "THE MORAL MINORITY"

Back in the 1980's Jerry Falwell promoted the concept of "The Moral Majority," a movement of Christian-led political action committees concerned with combating the decline of morality in this country. The group broke up in 1989 but you still hear about it now and then through religious organizations and churches. Frankly, I think the Moral Majority lost its war which is why I refer to it now as "The Moral Minority." And my peeve is not really about these people; its more about the moral decay of the country.

I believe there are two reasons for the decline of morality in this country: changing socioeconomic conditions and the rise of technology. I don't think its because we don't want to be moral, but we tend to take the path of least resistance and "go with the flow." As to society, lying, cheating, backstabbing, and plagiarism are now considered acceptable forms of behavior, particularly in our schools which is where they learn it from. In terms of economics, the average person is grasping at straws to make ends meet. For example, there are now more pyramid schemes, telemarketing, and fraudulent e-mail scams than ever before. Identity theft is also considered a serious problem. Just twenty years ago we never thought about identity theft. I'm sure it was there, but there was little concern over it.

In terms of technology, I believe there is a direct relationship between the rise of technology and the decline of our socialization skills. For example, I was in the garden section of one of the mega-hardware stores recently. As I was in line to check out, the woman in front of me was talking nonstop to a girlfriend about some inconsequential triviality on her cell phone. When she got up to the counter, she kept on talking right through her purchase and treated the clerk like he wasn't even there. When my turn came, I asked the clerk if this frequently happened. He said it was becoming more commonplace and he considered it rather rude.

As another example, the kids today all seem to have a cell phone with text messaging capabilities. In the classroom, they send messages electronically, such as love notes and answers to test questions. They have also devised a cryptic shorthand code to communicate by text messaging. The kids love this, but they still have problems writing a paper, articulating an argument, or just holding a simple conversation.

To my way of thinking, the decline in morality is our Achilles' heal. And we feel the effects of it in such things as the decline of craftsmanship, ethics, pride in workmanship, and our general resolve to get things done. I think the decline of morality can be traced back to bad parenting for the socioeconomic reasons mentioned earlier. As my grandmother used to say, "Children are raised by amateurs, not by professionals," and there is a lot of truth in that statement. Too often I see parents abdicating their responsibilities to teachers, coaches, baby-sitters and nannies. Instead of taking an active role in the child's life, they are content to let someone else do it.

I had a friend recently tell me there are too many rules in our institutions today, be it in schools, on the playing field, or in offices; that we need less rules so the individual can blossom and express themselves. Sounds nice. But keep in mind, we write rules for people who are going to break them, not for those who will adhere to them. In this age of parental abdication and moral decay, I'm afraid we're going to need more rules, not less, if we are ever going to realize any consistency on morality.

I'm sure the Moral Minority is still alive out there, but they are frustrated in terms of what to do. I can only suggest two things: first, lead by example - do what is right, not what is always expeditious; we need some real heroes for our youth to emulate, not some comic-book figure, but someone with the moral fortitude to do what is right, even in the face of ridicule. Second, we need to recognize and support those individuals and institutions that promotes morality or teaches it, be it our places of worship, our fraternal and civic societies, and particularly our schools. Here's one for you: How about setting up a pyramid-scheme that promotes morality as opposed to another crackpot marketing scheme?

I'm reminded of a warning issued by Arnold Toynbee years ago, the famed English historian said, "Civilizations die from suicide, not by murder." I'm just concerned that our moral decay is leading to our suicide.

Such is my Pet Peeve of the Week.

"PRIDE" METHODOLOGIES FOR IRM

Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at: http://www.phmainstreet.com/mba/pride/

AND FINALLY...

I received an e-mail from a J.B. regarding my essay from a couple of weeks ago entitled, "Managing Virtual Project Teams."

J.B. writes -

"Call me old fashion...even if I'm just 31, but managing a virtual team versus a in-house team is a completely different story and even though we have fabulous support from the technology there is nothing that is comparable with having one team around the table. You never get the correct dynamic and interpersonal collaboration when you have virtual team.

Yes, the technology opens up new possibilities of utilizing competence overseas but first your choice should be to have all in the same room, at least until somebody has proven me otherwise...

I read your blog and I agree with your three bullet points but I miss the vast need of communication when you have virtual team. For me communication is very important when you have a in-house team but it becomes even more important when you manage a virtual team. Without good communications, your team will maybe proceed forward but are they moving in the right direction...?

Technology is great but human interaction is better!"

Thanks J.B. for your comments.

Yes, you are right in that it is better to have the human dynamics for a single project. My post was designed for those who opt not to go this route but have a distributed project team instead. The technology is nice but there's nothing better than meeting with the project team face-to-face.

Again, thanks for your e-mail. Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

http://phmainstreet.com/mba/

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@phmainstreet.com

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2007 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END