Handling office politics from the outside

One of the reasons I became an independent consultant was to get away from the various interpersonal conflicts that recur in an office setting. Simply by putting my stakes down off the org chart, I avoid all manner of intrigue over power plays, office gossip, discontent with policies and procedures, and a whole host of other miscellaneous useless discussion that my regularly employed colleagues have to deal with on a regular basis. Even if I have an opinion on one of these topics, I think it prudent to remain silent unless asked to contribute — and even then to try to maintain as neutral a tone as possible.

But sometimes it’s not quite so easy to divide between “office politics” and the portion of my clients’ business strategies for which I bear some responsibility. The very fact that humans are involved means that many business problems cannot be separated from social problems. No matter how emotional the discussions, if the decisions that come out of them could impact the quality of the solution I’m attempting to help my client achieve, then I’m duty-bound to participate.

Some things to remember when jumping into the fray:

1. Business first. My client is in business to make money, not to run a social club, a forum, or a charity for its employees. My suggestions need to focus on what promotes business success. Employee satisfaction can be a big component of that, but it’s secondary.
2. Who’s your Daddy/Momma? Maybe most of the time my client’s company is one big happy family, but if it comes down to conflicts between various powerful people in the organization, then I must remain loyal to the person who controls my contract. If I disagree with them on an issue that has become inflammatory, then I’ll try to reason with them privately instead of adding fuel to the fire.
3. Be friendly to all sides of the argument. Don’t make things worse by acting in a partisan manner. Try to reconcile the different viewpoints, without belittling the importance of any argument. Being an outsider may help with the perception of disinterested objectivity.
4. Just add humor. Many times strong emotions can be diffused by revealing that the topic shouldn’t be taken too seriously. But sometimes that can backfire, so I have to choose my lines well. Best not to joke on the main source of contention, but rather on some aspect of it that everyone can find absurd.

I’d like to be more specific about the incident that sparked this post, but then I’d be violating rule #5:

5. Don’t blog about it. In fact, don’t discuss it with anyone outside the organization. I signed an NDA with my client, which means that they let me in on internal affairs that they don’t expect me to share. It’s not a matter of freedom of speech, it’s a matter of trust.


courtesy @TechRepublic

Find errors as early as possible on your project

Project teams generally use three types of quality management activities:

* Quality planning
* Quality control
* Quality assurance

The purpose of quality assurance is to prevent as many errors as possible by having sound processes in place to begin with. The purpose of quality control is to inspect or test the deliverables to find as many remaining errors as possible.

One important aspect of quality control is to find errors and defects as early in the project as possible. Therefore, a good quality control process will end up taking more effort hours and cost upfront. However, there will be a large payback as the project progresses.

For instance, it’s much better to spot problems with business requirements during the analysis phase of the project rather during the testing process. If you see the problem during the requirements gathering process it might just take a call to your client and the quick update of a Word document to fix it. On the other hand, if you discover this problem in the testing phase, it could impact the business requirements, the solution design, and some of the construct work. It will also require you to re-test the solution again. As you can see, this is a potentially huge impact to your project.

Likewise, if you were manufacturing a computer chip, it would be much cheaper to find a problem with a computer chip when the chip is manufactured, rather than have to replace it when a customer brings the computer in for service after a purchase. In fact, if the error isn’t caught until after the chip is sold to the customer, the cost to make the repair might cost more that the entire cost to manufacture the product to begin with.

There was a project early in my career that applied poor shortcuts to the development process. Since the programmers were under time pressure to complete their modules, they figured they would write the code and make sure it compiled cleanly. Then they would then call the module complete, with the attitude that they could “fix it in the testing phase.” They thought that they were just deferring their unit test time until later in the project. But by pushing these errors further downstream, it actually took much longer to fix the problems later - to the detriment to the overall project.

In Figure A, we see a traditional approach to finding errors.
Figure A


On many projects the team plans to find as many errors as possible during the testing process, with some errors not caught until support/maintenance.

In Figure B we see the better approach. It is much better to catch any errors that are introduced as quickly as possible. In other words, errors in the deliverable created in the Analysis Phase should be caught in the Analysis Phase; errors introduced in the Design Phase should be caught during the Design Phase, etc. This greatly minimizes the impact of correcting the errors.
Figure B

The bottom line is that the project team should try to maintain high quality and low defects during the deliverable creation processes, rather than hope to catch and fix problems during the testing phase at the end of the project (or worse, have the client find the problem after the project has been completed).

courtesy @TechRepublic