February 5, 2007

"BEWARE OF THE CHANGING OF THE GUARD"

In past essays, I have discussed how the corporate culture can be greatly influenced by the "Top Dog," meaning the head of the company. There are also subordinate "Top Dogs" who lead departments and their influence is limited only by what is allowed by their superior. This can be considerable if departments or divisions operate autonomously and inevitably results in subcultures that often operate at odds with the overall corporate culture. This phenomenon is particularly apparent in IT Departments who often have a revolving door policy for appointing managers or directors. This "changing of the guard" can be construed as good or bad depending on the current environment. What is important for the employees in the trenches is how to roll with the punches during this transitional state from one manager to another. Let me give you an example.

INSURANCE COMPANY

Years ago, we were engaged in a consulting contract with a large insurance company located in Toronto. Prior to our contract, the IT department was in disarray. End users weren't happy with their systems, they didn't trust the information produced, projects were late and over budget, and nothing was documented, making maintenance a nightmare. Things were so bad, that the executives were dependent on a certain systems programmer remembering to run the year-end financial reports (usually late). The current IT Director liked to hobnob with the corporate brass instead of his own staff, thereby leaving them in the dark. This helter skelter mode of operation affected harmony in the IT staff who ran around second guessing as to what was to be done. Conditions became so intolerable that the IT Director was finally ousted and replaced by a senior end-user who was also the most vocal critic of the department. Interestingly, he had no prior experience with systems and computing but was bent on cleaning up the mess left by his predecessor. This is when we were asked to come in.

Remarkably, the IT Director didn't find it necessary to fire anyone from the current staff but, instead, instituted a new organizational structure, imposed discipline, and created a quality consciousness. We were contracted to install the "PRIDE" Methodologies for IRM which greatly facilitated his goals.

To overcome his immediate problem of constantly working in a fire fighting mode of operation, his first project was to document the company's information resources, which was no small effort. There was a great temptation by developers to try to correct or improve the existing systems but, based on our suggestion, they resisted doing so since it would have resulted in a never ending project. Instead, problem areas were identified, cataloged, and prioritized. After the documentation project, this listing was used to formulate a systems strategy for improvements.

The documentation project benefited the company almost immediately. First, Operations began to run smoothly and on time. For example, with adequate documentation in place, they were no longer at the mercy of waiting for the systems programmer to run the year-end financial reports. Further, redundant data bases were spotted and merged, thereby bringing consistency to the information being produced. Also, the IT staff's morale picked up noticeably during this period as they now had a sense of direction and were cognizant of the strengths and weaknesses of their systems. Over the next few years, the company went on to conquer several major systems assignments much to the delight of the end-users and executive management.

Inevitably, the honeymoon came to an end when the IT Director announced he was going to retire after many years of service to the company. Unfortunately, he was not allowed to appoint his successor. Instead, he was replaced by a younger manager (30-ish) who was recruited from outside the company by an executive search firm.

The new IT Director was touted as a whizz kid who was intimate with the latest technology and wanted to make a name for himself. To do so, he had to distance himself from his predecessor and began to dismantle the organization and methods, and replaced them with 4GL's and other program generators. The new tools were impressive but the staff became unnerved when the Director disbanded the methodologies that worked in the past, and removed the IRM Repository containing all of the intelligence of the company's information resources.

I had an occasion to visit with the new Director to discuss his plans and, on behalf of the staff, pled with him not to delete the IRM Repository as it represented a substantial investment by the company and could be used to interface with his new programming tools. The Director was undeterred and went about his plans. Although his new tools could generate software at an impressive speed, documentation was sacrificed, data redundancy raised its ugly head again, and a rift began to reemerge between the end-users and the development staff. After only a few months under the new regime, the developers found themselves again putting out fires as opposed to upgrading or developing new systems.

CONCLUSION

The roller-coaster ride experienced by the IT department in Toronto has been played out time and again in many other such organizations. It seems IT organizations go through cycles, such as from bad to good, and back to bad again (as in the case in Toronto). Others seem to go from bad to worse; and some from bad to outsourcing. Regardless, the IT staff should be ever watchful of any change at the top and observe the executive's management philosophy as it will impact the corporate culture you are living in. As I mentioned in my essay on Corporate Culture, in order for employees to succeed, they must be able to adapt to the corporate culture. This usually means that it will be you, the employee, and not the manager who will have to adapt. But do not despair; let us not forget that the average tenure of service for an IT Director is under three years.

And in case you are wondering, Yes, the insurance company is again dependent on the systems programmer to run the year-end financial reports.

OUR BRYCE'S LAW OF THE WEEK therefore is... "Its never lonely at the top of an IT organization, primarily because the IT Director is never there."

"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/

MY "PET PEEVE OF THE WEEK" IS "SYSTEMS DEVELOPMENT PRIORITIES"

You know you're getting older when people start taking exception to how you do things; that it is now considered "old fashioned." And I guess I'm getting on in years as I observe how systems development is being performed these days. When you listen to the proponents of Agile methodologies, you hear that the real work in development is in programming. In fact, they resist all temptations to document anything about the design of anything, including a single program. But actually, I don't think much has really changed over the years. People have always viewed programming as the "real work" of systems development, and that we should expedite all other efforts, such as requirements definition and design, so that we can get down to the business of programming as quickly as possible. I think a lot of this has to do with the visibility of programming. People tend to assimilate such things as source code and executable programs with screens and reports. They really don't appreciate the need for the overall architecture of a system though, perhaps it is a more nebulous concept for them to understand.

The difference between designing a total system and coding a program is the difference between logical and physical, and is analogous to engineering and construction. The logical design of a system represents the engineering side of the house, and construction represents the physical side. When we design any structure, be it a building, bridge, automobile or whatever, engineers first study requirements and render a design of the product, usually in the form of a set of blueprints. From these blueprints, construction workers begin to assemble or construct the product accordingly. Trying to imagine construction workers operating without a set of blueprints is ridiculous, yet, this is precisely what we are experiencing in today's systems development world. Instead of laying out the designs, today's developers typically construct a shell of a program and then modify it until they wear out the user. In other words, programmers are trying to perform systems design at the wrong time. This trial and error approach tends to be a very costly approach to development as it involves several revisions until the program is completed. In addition, programs constructed in this fashion tend not to interface well with other components of the overall system. I am reminded of one of our Bryce's Laws whereby, "If we built bridges the way we build systems in this country, this would be a nation run by ferryboats."

I therefore question our priorities in systems development; haven't we got the cart before the horse? Shouldn't we be spending more time specifying the requirements and designing the system before we go to programming? If we did, we could greatly simplify programming simply by providing better specs. But the argument I typically get is, "Gee Tim, what you say all makes sense, but we don't have time to do things right." Translation, "We have plenty of time to do things wrong."

It is simply an erroneous concept that a developer is not being productive unless he/she is programming. To me, the real work is upfront, and not in the back-end. But then again, I'm being accused of being "old-fashioned," to which I plead, "Guilty, most guilty."

To my way of thinking, programming is primarily a translation function, where you take designs and convert them into machine processable instructions. I also believe programming should only take up 15% of the overall development process with more time spent up-front in systems analysis and design. Unfortunately, nobody in this country seems to be willing to do the up-front work, consequently they spend 85% of their time in programming.

Just remember, its "Ready, Aim, Fire"; any other sequence is simply counterproductive.

Such is my Pet Peeve of the Week.

eBOOK: THE BRYCE IS RIGHT!

Folks, be sure to check out our eBook entitled, "The Bryce is Right! Empowering Managers in today's Corporate Culture." This is a frank and candid description of the state of the art in management and includes essays on the problems in management today, along with some pragmatic advice on how to deal with them. Basically, this is a condensed course in management. As such, it is suited for managers, either those aspiring to become a manager or for those who need a refresher course. It will also be of interest to young people entering the work force, and is excellent for college curriculums.

Charles Cole of Lyndhurst, OH, said it is a "Very interesting book. Good work! It reminds me of some of the early works I read by W. Edwards Deming. Too bad the American corporate gurus of his day didn't pay him heed."

And Wolf Hager of Fort Myers, FL, says it is "A very impressive publication which requires careful reading and reminds me somewhat of Peter Drucker."

The price is just $20 plus tax. For more information on our book or to order on-line, see:

http://www.phmainstreet.com/mba/bryce1.htm

We have also produced a new one-day training program of the same name. For more information on both the eBook and course, please visit our web site at:

http://www.phmainstreet.com/mba/bryce1.htm

While there, look for our MS PowerPoint presentation describing both the book and the training program.

AND FINALLY...

I received an e-mail from Bob Carlson in Los Angeles who wrote me regarding last week's essay, "Effective Screen Design."

Bob writes:

"I loved your article on screen design, but one question; are there any standards for web page design?"

Thanks Bob for your note,

Good question. Regrettably, there are no industry standards for web page design. I wish there were. You may remember me commenting last month on the state of web page design. My gripe was not about the graphical design of the web page but more about the lack of standards in terms of general layout and navigation. Whereas in the world of GUI screen design, there is general agreement in terms of action-bar-choices like "File", "Edit", and "Help," as well as "OK/Cancel" pushbuttons; there are no comparable standards in web design. Instead of simplifying life for everyone by standardizing on the navigation of a web page, the user must learn how to navigate each web site separately. This one small problem greatly complicates surfing the web. For example, there should be standard sections for "About Us", "Contact", "Cover/Main", "FAQ", "Search", "Logins", and "Help" (which I personally consider atrocious on most sites).

I just went through an in-depth evaluation of Internet shopping carts, gateways, and merchant accounts for a project I am working on. Because of the lack of standards, I estimate this project took me four times longer than it should, simply because I had difficulty finding the answers to my questions. I consider myself rather proficient in the surfing of the Net. And if I am having problems, consider John Q Public who is stumbling around out there.

I believe the lack of standards is costing us billions of dollars in terms of lost time; it is also crippling sales. Always remember this, clever graphics are nice and have their place, but more than anything, people on the Net want to get answers to their questions quickly.

I just wish some of the web design tools out there had enforceable standards like the screen design tools do or some way to analyze a web page for consistency.

As I always lament, "God forbid we should ever have any standards in this industry."

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