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

April 23, 2007

"SYSTEM TRAINING TIPS"

Okay, you've built this wonderful new "state of the art" system. Now comes the hard part: startup. To do so, you will have to train the user community in how to effectively use the system. Do not underestimate this task. Now is not the time to grasp defeat from the jaws of victory. Let me give you an example; years ago my wife was a contract administrator for a large jet engine manufacturer in the Midwest. Basically, her department was concerned with ordering parts for the jet engine assembly lines and making sure they were delivered on time. Most of this was done using parts catalogs, index cards, and a lot of telephone calls. It may have been a bit clumsy, but it worked. Wanting to expedite this process, the systems department invented a new Materials Management System (MMS) which was to be used to order and track parts, as well as to interface with the company's Finance System to evaluate engine costs. After the systems department built the MMS, they called for a training session to introduce all of the contract administrators to the new system. At this time, they gave everyone a new TI Silent 700 computer (which featured acoustic couplers at the time) and a list of cryptic commands on to how to use it. The whole session lasted about one hour and did more to confuse the users than to educate them. So much so, that on the Monday when the MMS was to be started, nobody used it and, instead, went back to their manual procedures.

Humans are creatures of habit and, as such, training the users on how to implement a new system must be handled carefully. And it is more than just having good educational skills, its about breaking habits and creating new ones. For example, years ago when companies were beginning to migrate away from DOS to operating systems with Graphical User Interfaces (e.g., Windows and OS/2), systems people were amazed to find the user community resisting the migration. Surely the new GUI-based operating systems were easier to use and understand, right? Maybe, and maybe not. A lot of users felt comfortable using their favorite word processors and spreadsheets under DOS. Why then, they questioned, should they be forced to move to something else? Good question, one that was seldom answered by I.T. departments. In this case, the answer was: first, to bring a uniform consistency (look and feel) to all applications on the PC, thereby simplifying the learning and implementation of programs, and second; industry trends (away from character based operating systems).

MY BACKGROUND

For the last three decades I have been teaching methodologies, be it related to systems planning, systems development, data base or project management. Frankly, I believe teaching the development staff how to use a methodology is more difficult than teaching users how to use a new system. Interestingly, systems people, who are supposed to be the agents of change, are remarkably the most resistant to it. Nonetheless, I have learned four important lessons from this experience which is applicable to training users in systems:

1. Provide a tutorial which describes the rationale for the new system, and defines its concepts and terminology. In other words, sell the system. Be careful to couch the presentation in terms the users will understand, and because of this, avoid introducing technical jargon as much as possible. You want to enlist support for the system, not provide excuses for not using it. Also, all questions should be welcomed and not ridiculed. User questions may appear trivial and foolish at times but your intention is to overcome all objections.

2. Provide "Hands On" Training - true it is important to give an academic explanation of how the overall system works, but it is also important for users to actually "touch and feel" the system. They may not come away from the training class as experts, but at least you will have overcome their fear of the new system.

For complicated processes, I tend to offer manually implemented exercises so the students would gain an appreciation for the need for automation. For example, in order for a person to appreciate a calculator, they should first have an appreciation of basic math. If the users understand the processes being automated, they will be more inclined to trust the new system.

3. Recruit Management Support - the implementation of a new system, like a methodology, requires the unwavering support of management. If the user community senses the slightest lack of support for the system, they will use it as an excuse not to use it. Because of this, I strongly encourage a representative from management to introduce the speaker/trainer and to monitor the training proceedings.

4. Create excitement to use the new system - this can be achieved several ways; for example, promotional buttons, pins, a kickoff party, endorsements, etc. Think of it as releasing a new product. Another option is to train the user community in stages, e.g., taking key "germ carriers" and making them proficient in the system before others, then let them spread the word to the rest of the user community. A little attention to key users can go a long way.

GENERAL TIPS

Aside from the system tips listed above, there are some general tips you should be cognizant of as a trainer:

1. Be organized - prepare a well thought out agenda and stick to it. I'm also a big believer of the military approach whereby you "tell them what you're going to tell them, tell them, then tell them what you've told them."

2. Know your audience - understand their intelligence level and interests, and design a training program around them, not the technology. Yes, you want them to move forward on technology, but you cannot afford to alienate them. By working within their limitations you will be able to accomplish more.

3. Dress and speak authoritatively - your appearance and how you present yourself says a lot to the audience about your system. If you dress and act like a geek, the user community might look upon this as another harebrained scheme by the I.T. department. The appearance and presentation of the trainer reflects the credibility of not only the speaker, but of the system as well. Do it first class and earn the respect of the students.

4. Stimulate the students; don't put them to sleep - keep the training positive and upbeat; inject humor where necessary. Allow periodic breaks, but keep them short and sweet.

5. Select a suitable venue - hopefully something where the attendees will not be distracted and allow them to focus on your subject.

6. Provide supplemental training aids - such as reference cards or perhaps a CD/DVD with a multimedia presentation (e.g., MS PowerPoint, Lotus Freelance, or a podcast). Blogs and discussion groups (list servers) are also useful to act as a clearinghouse for answering questions.

7. Critique the training program - allow the students to evaluate the training course. Their feedback will hint as to your success and may point out problem areas that need to be addressed.

CONCLUSION

As someone charged with a key role in changing the status quo, the systems trainer must first understand that his audience does not necessarily want to change. Some of the users will welcome change as they are aware of the shortcomings of the current system. However, others have adapted and feel comfortable using the current system regardless of its shortcomings and, as such, will resist change. The trainer is left with the task of convincing the users not only is the current system inadequate, but that he has a superior alternative to replace it. After all, you cannot treat a patient if he doesn't know he is sick.

Just like your systems development efforts, training requires planning, organization, execution and review. Too often I have seen companies underestimate the training effort and put forth only minimal effort to properly train the user community. Such shallow thinking inevitably leads to disaster later during system startup. I have even seen disgruntled users sabotage the best of systems simply because they didn't understand it or it was not presented well.

The system trainer's mission, therefore, is to explain, demonstrate, and convince the users how the new system will not only benefit the company, but the users as well; and communicate it in terms the user community will understand. Remember, a verbosity of technical jargon impresses nobody but yourself.

OUR BRYCE'S LAW OF THE WEEK therefore is... "You cannot treat a patient if he doesn't know he is sick."

MY "PET PEEVE OF THE WEEK" IS "WEATHERMEN"

Whether you call them "Weathermen" or "Weather people," I'm a little concerned over their ability to accurately predict the weather. Back in the early days of television, the weatherman was that person in the station who knew the area and seasonal weather patterns, checked the barometer, and was smart enough to stick his head outdoors before going on the air to discuss the weather. Since then we have introduced satellite imaging, radar, fancy computer graphics, and now the people prefer to be called "Meteorologists." Despite all of this, I find it amazing they still can't predict the weather with any accuracy. Rarely will they go out on a limb and predict rain or snow until it finally hits us. In particular, I love it when they say there is a 50% chance of rain. Why don't they just admit they haven't a clue as to what is coming and toss a coin on camera?

I also find their body language in front of the weather maps amusing, where everything is choreographed as they dance around the screen. I have a friend who works at CNN who gave me a tour of their studios in Atlanta a few years ago where I watched a young weatherman go through his paces in front of a blank wall. I thought is was rather amusing watching this firsthand with no graphic in the background.

A lot of people use the weatherman position as a starting point for their television career. Most use it as a jumping-off point to get them into news or entertainment. I think David Letterman is perhaps the best example of this as he started out by reporting the weather in Indiana.

Reporting the weather can be outright boring, small wonder they like to clown around on camera to keep the viewer interested.

As for me, I just wish the weatherman would just get to the point and tell me what the current weather conditions are and what to expect in the next couple of days. Although its nice to know what's going on in the rest of the country, how about we focus on our own local part of the world for starters? Even better, I think they would have a heck of a lot more credibility if they just stuck their head outside before they reported the weather.

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 a lot of e-mails this past week from our listeners related to my "Pet Peeve" on "Divorce"; first, I heard from CB in Australia who writes:

"Australia's divorce rate has been sitting above 50% for a while now. The biggest impact to the divorce rate was the introduction of the "no fault divorce" in the sixties, and the family law act in the mid seventies which made it easier for women to get a fair share of the family assets after a breakup. That and the declining marriage rate. Strangely, people in defacto relationships have a good chance of sticking it out."

Next, I heard from an A.M. who writes:

"Tim, Is it divorce or lawyers income that upsets you most? Do I understand you correctly, that you're going to tell your daughter/son to go live with Mr/Ms Right (or perhaps four or five Mr/Ms Rights till see/he rolls over one morning and says this is Mr/Ms right) so she/he can live happily ever after? Seems these arrangements are highly suspect. Current divorce percentages and lawyers included. I believe all relationships should be based upon solid principles, deeply set in honest high moral values. Obviously moral values are lacking or of no concern in American Society. The idea of redemption as a means to cure our mistakes is a second thought, when most likely Americans knew better the first time and were too selfish, lazy, or lustful to make the first decision (enter into a principled relationship) the only way to go. The real faults lay upon the children they begat. We are in an era of self gratification, with morals not even being discussed. There is no light in the end of the tunnel."

Next, I heard from James who writes:

"Interesting that you post this on the anniversary of my divorce. As to the other comment posted here, all the principles in the world won't help you when someone decides to try to destroy your life. Blame society if you like, but it fails to address the issue. Most divorce happens the way mine did, one person with all the power destroying the other who wants to stay together."

And finally Randy writes:

"I agree - the single point source is no-fault divorce. While declining moral standards are the root cause, no-fault divorce encodes into law those reduced moral standards. (Yes, this is legislation of morality - low morality.) Quite honestly, no-fault divorce has reduced expectations when entering into marriage - "if it doesn't "work out," I can always get out of it"; and variations on that theme abound. Plus, no-fault divorce was (in many areas) presented as an "escape" for persons caught in an abusive marriage where abuse was difficult to prove, while the reality in practice has been that no-fault divorce has been a tool used by abusers to inflict even greater and longer-lasting damage (mental/emotional, financial, professional, and legal) on their victims - if anything, the overall damage caused by abusers has increased, not decreased, where no-fault divorce has been implemented. (Perhaps the typical change in the gender of the victims after no-fault divorce is implemented makes this result acceptable to some.)"

Regarding my Pet Peeve of "Turning Crap into Gold," I heard from F.D. in Edmonton who said,

"You wouldn't believe how close I came to buying a PC in 1985... I completely stumbled on the Macintosh and a young fellow who showed me the difference between price and cost!... I was about to spend $1,600.00 through the franchise I was involved with for a PC and instead bought a Mac for $8,500.00... I have never had to train to use it! I have never had a crash of any description! I have never had a virus! AND I have been running Windows XP (because some programmer made a couple of internet sites I require browser specific!) along with OS-9 and OS X... all at once!

I am about to purchase the new IMAC with a 24" monitor and the Intel chip... this runs the "Bill Gates crap" better than the clones and unfortunately there will always be narrow minded programmers around that make programs ONLY compatible with Windows... I need Windows for 2 things with the Real Estate and other than that it sits dormant... I really wouldn't need Norton if it wasn't for Windows... by the way, it is much more stable on Mac than on a clone.

That first unit I bought in 1985?... it still functions well and makes a great conversation piece!"

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

April 16, 2007

"HOW EFFECTIVE WERE YOU TODAY?"

Okay, you believe you had a great day at work today; that you accomplished a lot. And maybe you did. Then again, maybe you didn't do as much as you might think. A lot of people believe just because they are a model of efficiency, they are being highly productive. This is simply not true. We have discussed the concept of productivity on more than one occasion in this column, but some trends in the I.T. industry have spurred me to revisit it again.

Perhaps the biggest problem here is that people fallaciously equate efficiency with productivity. They are most definitely not synonymous. Efficiency is concerned with speed of delivery, reduced errors, and minimal costs or effort. In other words, how fast we can perform a given task, at reduced costs, without committing any substantial errors in the process. But what if we are performing the wrong task at the wrong time? Obviously this would be counterproductive regardless how efficiently we performed the task. I always use the example of industrial robots on an assembly line, whereby they can perform tasks such as welding very efficiently. But if they are welding the wrong thing at the wrong time, they are counterproductive.

This means there are two variables involved with productivity: efficiency and effectiveness. Whereas efficiency primarily deals with speed and "doing things right," effectiveness is concerned with "doing the right things." In other words, working on assignments in the right sequence. Sequence can be defined for a single project by its work breakdown structure (WBS) and precedent relationships, or for working on multiple projects based on priority.

ANALYZE THIS

To illustrate this point, let's consider your work activity today (either perform this analysis at the end of the day, or for your last business day). Write this down on a piece of paper:

1. First, let's define your EFFICIENCY rating for the day; as guidelines, use the following:

1.00 - I was a dynamo today; worked fast, no errors.
.75 - I did more than my share, not too many mistakes.
.50 - I did my fair share, average number of mistakes.
.25 - I was below average, some mistakes.
.00 - Had a bad day; too many mistakes, a lot of time lost.

Enter your EFFICIENCY rating here: __________
(enter any number from 1:00 High to .00 Low)

2. Make a list of your work assignments IN PRIORITY SEQUENCE; (list at least your top five assignments, regardless if it is within a single project or involving multiple projects; obviously you may have more assignments, but let's limit it to five for the purpose of this exercise):

1. __________________________________
2. __________________________________
3. __________________________________
4. __________________________________
5. __________________________________

3. Account for your time during the day using the following variables. Be honest.

A. WHAT WERE YOUR "TOTAL HOURS IN DAY" (THD)
(The total number of hours spent at work)

___________ hours

B. Of the THD, how much time was spent on interferences or activities not directly related to your work assignments (e.g., breaks, lunch, meetings, reading, surfing the web, e-mail, correspondence, telephone, travel between appointments, etc.)?

___________ hours

C. Enter the number of hours spent during the day on your top five priorities (enter "0" if you didn't work on something); then compute the extended number according to the equation shown:

HOURS EXTENDED #1 Priority (___________ / THD) X 1.00 = ___________ #2 Priority (___________ / THD) X .90 = ___________ #3 Priority (___________ / THD) X .80 = ___________ #4 Priority (___________ / THD) X .70 = ___________ #5 Priority (___________ / THD) X .60 = ___________

Note: The hours reported here, coupled with the time recorded for interferences ("B"), must equal the Total Hours in Day (THD). Also, the rates used in the computation are based on priority (highest to lowest).

4. Add the EXTENDED numbers of all five priorities: ___________
(This is your "Effectiveness" rating)

EXAMPLE

A. WHAT WERE YOUR "TOTAL HOURS IN DAY" (THD):

8 HOURS

B. Of the THD, how much time was spent on interferences or activities not directly related to your work assignments (e.g., breaks, lunch, meetings, reading, surfing the web, e-mail, correspondence, telephone, travel between appointments, etc.)?

2 HOURS

C. Enter the number of hours spent during the day on your top five priorities (enter "0" if you didn't work on something); then compute the extended number according to the equation shown:

HOURS EXTENDED #1 Priority (1 / THD) X 1.00 = .125 #2 Priority (1 / THD) X .90 = .1125 #3 Priority (0 / THD) X .80 = 0 #4 Priority (0 / THD) X .70 = 0 #5 Priority (4 / THD) X .60 = .3

4. Add the EXTENDED numbers of all five priorities: .5375
(This is your "Effectiveness" rating)

PRODUCTIVITY = EFFECTIVENESS X EFFICIENCY

Let's put it all together now and compute our Productivity. Let's first start with our example; let's assume we had a pretty good work day and our Efficiency rating (as defined in step #1) was .75. When we multiply it against our Effectiveness rate, we get .403125 .

Next, let's compute YOUR numbers:

__________ EFFICIENCY (from #1) X __________ EFFECTIVENESS (from #4) __________ PRODUCTIVITY

To calculate your own productivity rating, see our "MBA Daily Productivity Analyzer" on our web page: http://www.phmainstreet.com/mba/mbaprod.htm

WHAT DOES THIS MEAN?

This is but a simple example. It is far from scientific (for example, the efficiency rating is crudely estimated without any level of precision). Nonetheless, the Productivity number highlights the differences between Efficiency and Effectiveness. Using the numbers in our example, if we were to use a perfect 1.00 Efficiency rating (as opposed to .75), the worker's Productivity rating would not be any higher than .5375. This is because the worker spent time on interferences/distractions and worked on other priorities that perhaps he should not have.

I have seen companies who like to plot efficiency ratings on a graph, but as far as I am concerned the data is misleading as they only portray a glimpse of a much larger picture. Plotting the effectiveness rating is just as important as the efficiency rating and helps produce a realistic productivity rating.

CONCLUSION

Some workers, particularly craftsmen, understand the differences between efficiency and effectiveness. They appreciate the total process for building something and are acutely aware of the potential risk for cutting corners. Some simply don't get it (and probably never will). For example, the I.T. industry commonly misunderstands this concept and is obsessed with efficiency. As evidence, consider the use of "Agile Methodologies" today which are quick and dirty approaches for writing a program. Here, a rudimentary program is developed, then radically refined over time until the client signs-off on it. Proponents consider Agile Methodologies to be a quantum leap forward in terms of productivity. I don't. True, they can write code fast, but because they are not well structured, a lot of time is spent revising designs and rewriting code, not just once but several times. Instead of getting it right the first time, Agile Methodologies rely on the efficiency of their power programming tools to make them look good.

So what is a good productivity rating? First, let's dispense with the notion of 100% productivity. This is purely a myth. This would mean that everyone in a company is being both highly effective and efficient around the clock. This is simply not possible. Our example herein shows a productivity rating of 40% which is probably closer to reality. In fact, 25% is considered a good rating and is typical for a lot of companies.

If this paper has done nothing more than raise your consciousness about the differences between effectiveness and efficiency, then it has served its purpose. Hopefully, it will cause you to refocus your efforts on "doing the right things" as opposed to just "doing things right."

So, how "effective" were you today? Your answer will say a lot.

As a footnote; If you are familiar with my writings on "PRIDE" Project Management, you have heard me talk about "Effectiveness Rate" in differentiating the use of time. What I am describing herein is not the same thing; similar, but not quite. Under the Project Management scenario "effectiveness rate" is an availability rating which is used for estimating and scheduling, but not for calculating productivity.

OUR BRYCE'S LAW OF THE WEEK therefore is... "Productivity = Effectiveness X Efficiency"

MY "PET PEEVE OF THE WEEK" IS "TURNING CRAP INTO GOLD"

Last week I suffered a major crash of Windows XP. This caused me to reinstall the operating system as well as the many programs I work with. Fortunately, I was well backed-up and didn't lose anything of substance; nonetheless, I lost a day and a half recovering from it. The week before that, a good friend of mine suffered a similar crash on his laptop which took him days to recover.

Not long ago you heard me complain how Microsoft products are actually counterproductive. Well, here are two fine examples of it. Instead of doing what we're paid to, both my friend and I lost considerable time fixing the operating system.

While I was reinstalling the operating system I was, of course, encouraged by Microsoft to upgrade to Windows Vista (like that would be better). Frankly, I've lost all confidence in Microsoft products and understand why so many of my friends and business associates are switching over to the Mac. We want confidence that our computers are industrial strength and aren't going to hiccup at the worst possible time for us.

I'm just amazed how blindly people follow Microsoft, be it at home or in the corporate world. I always chuckle when I hear Bill Gates described as a technical genius. A marketing genius, yes, but a technical genius? Hardly. To me, Gates is living proof that you can indeed turn crap into gold.

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 a lot of e-mails this past week from our listeners; first, I heard from "The Great One" in Sarasota, Florida regarding last week's essay on "Virtual Project Teams"; he writes:

"Your essay on virtual teams was on the mark. Having extensive experience on working and managing virtual teams I would like to stress the most critical factors to success:

1. Holding weekly meetings with all team members following a structured agenda and meeting etiquette.

2. Prior to meetings, team members forward their status reports to the project manager and report any critical issues PRIOR to meetings such that the project manager has a chance to digest, analyze, and action resolutions...bringing large issues to the meeting is inefficient and counterproductive to the rest of the team.

3. Team members report on their progress at each meeting giving the entire team a view to the overall project picture.

4. The Project Manager should conclude the meeting with general announcements, perhaps praise noteworthy events, and point out any important procedural requirements.

I agree that working in a virtual mode brings the need for carefully planned projects following some form of methodology to the forefront.

My pet peeve is that when an individual who is an in-house type of person working from home consistently shows up late to virtual meetings and falls behind in their work, they should be brought back in house for a time until their work habits are brought back in compliance. Working from home is a privilege, not a right..."

Next, I heard from some listeners pertaining to some of my recent "Pet Peeves of the Week."

First, I received a note from a DW in Toronto regarding my "Fascination with Celebrities" column. DW writes:

"I think its the 24 hour news channels, Larry King, and all the Entertainment TV shows that keep all of this in our face more than it used to. More bandwidth needs stuff to fill it and still make money, so easy stories get airplay

It is the "tabloidization" of the media. Paper tabloids have been with us much longer, like in the movie "LA Confidential" (was that art? dunno...). I swear I would do all my grocery shopping at a store that banned tabloids at the check-out counter.... but that's about as likely as getting my spouse to stop watching Entertainment Tonight.

So, is our interest in celebrities/entertainers new? No, it can start with Mozart and Liszt, on to Dickens and Twain, then to non-entertainers like Lindburgh. Again, its the "fill the bandwidth" issue."

I also received an e-mail from a FD in Edmonton regarding my "Birthdays" Pet-Peeve where I complained how we tend to celebrate the wrong things. FD writes simply:

"The alternative to another birthday is certainly not a pleasant thought!"

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

April 9, 2007

"MANAGING VIRTUAL PROJECT TEAMS"

These are interesting times for managing systems development projects. In the old days (as late as the 1980's), whenever a development project was initiated, it was necessary to form a project team at a centralized geographical location in order to expedite communications between project members. But now we live in an age of electronic communications that provides greater flexibility in terms of allowing workers to work just about anywhere; some are at a central office, some are at home, some are consultants operating off-site, some are overseas in Timbuktu. Thanks to such things as collaborative software, the Internet, cell phones, etc., development staffs are as distributive as the systems they are trying to build. Whereas the development staff used to personally know all of the people participating on a project, now it is common for people not to be able to match a face to a name, be it nothing more than a UserID or an e-mail address.

Although electronic communications is useful for instant messaging and exchanging design documents and files, interpersonal relationships are often sacrificed, and this is a vital part of any project. After all, if we do not know anything about an individual, we are less likely to trust and work with them effectively. Consequently, Project and Systems Managers ask me for advice on managing virtual project teams for which I offer three suggestions:

1. Identify your cast of characters - for all members of the project team, define the project infrastructure in terms of administrative reporting relationships, along with a personnel roster. Such a roster should identify each person by proper name, nickname, and photo. There should also be contact data (including physical location), the duties and responsibilities of each person, and a brief biographical sketch describing each person. Such a sketch is invaluable for promoting understanding and trust between project participants.

2. Define standard methods, techniques and tools. Since there are conceivably as many interpretations of systems development as there are project members, it is necessary to develop a standard and uniform approach that will result in consistent and predictable results. This means processes (phases of work) must be defined in terms of standard deliverables and review points to substantiate completeness, and standard techniques and tools to be used in the development process. Such standardization eliminates confusion and materially assists the project team in communicating on a common level, regardless of where they are geographically located.

3. Establish standard and routine project reporting cycles. Here, a good Project Management system can be invaluable. At minimum, project status should be reported on a weekly basis. If it is not possible to hold an on-site project review meeting in person, try holding an on-line meeting instead. Internet chat sessions and video conferencing have become very effective in this regards. The only problem though is knowing whether the participants are truly paying attention. A private project blog or discussion group can also be helpful for reporting problems and project status, as well as establishing punch lists and providing a clearinghouse for solutions.

CONCLUSION

When you think about it, there is actually nothing here that shouldn't be done under normal operating conditions where all participants are on-site and present. Electronic communications simply begs the issue. It also means standard methodologies, like "PRIDE," are just as important today as they were yesterday, perhaps more so.

Consider this, without such standardization, offshore programming is not truly feasible. Collaborative software, the Internet, and all of our other communications vehicles are nice, but without an organized and standardized development environment, chaos will inevitably ensue.

OUR BRYCE'S LAW OF THE WEEK therefore is... "Our electronic communications may be very slick, but if neither party knows what the other is talking about, you are going nowhere fast."

MY "PET PEEVE OF THE WEEK" IS "DIVORCE"

I recently read the divorce rate in the United States is at an all-time high of 47%. This jives with a lot of friends of mine who have also been divorced, as well as my High School class. I even had a classmate who was married three times after being out of school for only five years.

Most of the divorces I have known of were simply because they married too young and didn't really know what they were getting into. Frankly, they married for lust as opposed to love. This makes me think that we make marriage too easy or convenient to get into without really thinking about it. Nobody offers a training program on marriage at the high school or college level. Most people simply jump into it and hope for the best, yet discover the worst, particularly the cold reality of divorce court. Maybe what we need is a trainer's permit or some sort of certification program before people are allowed to marry. In other words, I think we ought to make it more difficult to marry as opposed to easier. Maybe we should treat a marriage license like we do earning a drivers license. For example, attend classroom instruction, pass a test, then get a temporary permit whereby the couple can live together, and if all goes well, you can get a marriage license. If it doesn't work, than no legal proceedings are required; the couple just separates. I would bet this would lower the divorce rate radically and put a lot of lawyers out of work.

I just think its odd that for an institution we consider so important that we put forth the least amount of effort to prepare ourselves. People should go into marriage with both eyes wide open, not their fly.

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 Martin Dimond in Ohio who wrote me regarding last week's essay, "Boxes and Lines."

Martin writes:

"You made an interesting comment about documentation at the program level, that it might not be necessary. Could you please explain this further?"

Thanks Martin for your note,

There are different methods of implementation for producing programs. In addition to the nuances of different programming languages, you have to look at the complexity of the program and determine if you are going to write it by hand or use some automated assistance. If you are writing it by hand, you'll probably use some sort of structured English or pseudo-code, and perhaps a graphic to depict the logic (I'm old school that prefers a good old-fashioned block diagram). But if you are using machine assistance, such as a program generator, report writer, or 4GL, you will have to input the logic according to the tool's particular specifications. In other words, different strokes for different folks.

I also received a comment from a JT in Palo Alto, CA regarding my essay a couple of weeks ago entitled, "The Ratio of Analysts to Programmers."

JT writes -

"Interesting post. There is some evidence that companies that adopt business rules even find themselves replacing programmers with business users who manage the rules as well as with analysts."

This is great if you can get away with it. Some of the older people in the end-user community might resist such effort, but the younger people, who are less intimidated by the computer, are more apt to do this and I see this as a growing trend. To do so, you need an easy to use tool to capture such specifications for use by programmers later on. To me, this is an IRM Repository.

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