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