Search This Blog


01 June 2014

Differences between Risks and Issues, Part 2

Differences between Risks and Issues, Part 2

Threats; and Another Side of Risk

Part 1 (click here) of this series defined issue.

Threat versus Risk

If a situation, such as a cause and its effect, is certain, then it is an issue. With risk, we deal with uncertainty. If the probability of something is zero, it has no uncertainty. If the probability is 100%, again, it has no uncertainty. The term Risk only applies when

0% < probability < 100%

In Risk Management, we avoid the term "threat" because in everyday discussion, "threat" could also mean "promise of harm" or "logical sequence resulting in harm."

For example, a bully "threatens" to call you a bad name. If we believe the bully, this type of threat would be an issue, not a risk, because there is no uncertainty. If we don't care what the bully says, there is no effect, so it is neither a risk nor an issue.

Another side of risk

Most explanations of risk concentrate on the probability of the event. What if the event is certain, but you don't know what the effects will be?

Risk has two real parts:
  • Cause - A condition or possible change in conditions
  • Result - The effect that may happen
Risk has a probabilistic part, too:
  • Uncertainty
PMP study materials usually focus on uncertainty about whether the cause will happen. However, we can also have uncertainty about what effect a condition or change in conditions may cause.

Therefore, a condition (or change) may be certain, but you still have risk if you have uncertainty about the results.

As PMs, we are communicators. We listen. Others often use terms and definitions different from ours. So we ask people what they mean and negotiate a common vocabulary. We do this to control the risk of broken communications.

If we find that somebody says "the bully is a threat" and means "the bully poses a risk," then we could enter this in the Risk Log in one of three ways:
  • There is x% chance that the bully will call another worker a bad name, causing that worker to quit.
  • The bully will call another worker a bad name, and there is y% chance that the other worker will quit.
  • There is x% chance that the bully will call another worker a bad name and y% chance that the other worker will quit.
If there is 100% probability that the bully has or will call the coworker a bad name and a 100% probability that the coworker will or has quit, then we have an issue.

And if you go around calling my coworkers bad names, we have an issue.

Further study: Use a search engine to learn more about "aleatory variability" and "epistemic uncertainty." However, please don't ask me about them because, the way other authors explain them, I do not understand at all.

(c) Copyright 2014, Richard Wheeler

25 May 2014

Influencing without Authority

Does anyone have advice or resources for managing up when you have proposal contributors or stakeholders who are Sr. to you? (Especially when they have no idea of proposal best practices but they still have...opinions). -- Etiak Y.

Learning to influence without authority

I love the way Etiak worded that, "but they still have... opinions."

My inability to manage or influence without authority hindered my own career. I didn't even know until a few years ago that it had a name.

Because my title (Senior Systems Engineer) did not match the titles of the supervisors and directors whom I was supposed to monitor as part of my job, I limited my attempts to influence them, even when they needed somebody to hold them accountable.

Because I did not see myself as having authority and did not know how to "influence without authority," those in authority did not see any reason to promote me. Remaining at the same level for decades will stunt and eventually kill your career.

Challenging authority challenges experience

Be sure you have a good case before challenging the stakeholders. What is the authority of your "best practices?" Have you considered the impact of the changes you want to make? What will stakeholders have to change in their current practices and relationships in order to make the changes you want? Will it really make a difference? Are you sure the customer is ready for the new practices?

Communicating the challenge

You might consider laying out, side-by-side, the old and new ways. Be ready to explain, "if we do it this (old) way, then (problem). The Standard recommends doing it that (new) way, which prevents (problem) and (other benefit)." Appealing to logic does not always work because "old ways" take root in the subconscious. You want them to visualize (fear) the problems of the old way and visualize the benefits (reward) of the new way. Communicating through story can help.

If you get buy-in from the stakeholders who are in your chain of command, then you move from a position of influencing without authority to influencing through the halo effect. That is, you borrow the respect given to those who wrote the standard; and as a representative of those who do have authority, you can get the other stakeholders to at least listen.

Manage issues with change

If you have to ask stakeholders to re-write their sections because you failed to communicate your needs, it will reflect poorly on you. Announce that the format will comply with (standards) at the very beginning. Help them do their parts correctly the first time by describing the purpose and methods at the very beginning. Give them templates or easy-to-follow guidelines.

Be sympathetic when people whine and moan, but remind them of how the new way provides a way to escape the problems of the old way, remind them of the rewards of the new way, and thank them for their flexibility.

More on influence

You can find materials on influencing without authority in various places. I just finished reading The Science of Influence, by Kevin Hogan (Wiley, 2005). Understanding more about influencing others will give you the side benefit of having more power to influence your own behaviors.

(c) 2014, Richard Wheeler

19 May 2014

Recruiting 101 says not to put salary ranges on job posts.  -- LinkedIn discussion

When only one party in a negotiation has intelligence on the other party, the other party will lose. This is counterproductive. When the losing employee realizes what has happened, he will lose motivation and become less productive, jump ship, or (in extreme cases) undermine the employer.

I'd like to clarify another concept: Suppose a company hires somebody who earns $10/hour and pays him $14/hour. The company should not view that as "giving" the worker a 40% "raise." It may be a 40% increase of income to the worker, but from the company's perspective, it's dividing by zero. Literally.
Raise % = (New - N/A) / N/A x 100%
You can only give a raise to somebody you already employ. Substituting a new hire's history for N/A is dishonest.
Moreover, the situation is like sunk costs. Sunk costs only have emotional value in decisions. Good managers base objective decisions on the value and cost going forward.

Take an extreme example: Suppose I fill time between jobs making $8/hour as a WalMart greeter while finishing my PhD. If I apply for a position that pays $88/hour at your company, are you really going to negotiate my new salary down to $10/hour with the argument that $88/hour would "give" me a "raise" that's too big? Or if you hire me for $88/hour, are you going to boast that you "gave" me a "raise" of 1,000%?

Employers and recruiters may think they have all the power. So do the sphincters in the alimentary canal; but what happens to the system when they abuse their power? Job applicants have power, too. Unethical applicants can become dissatisfied losers in the negotiations and undermine the company; the best applicants can walk away and find competitors that will reward them for moving their companies forward.

If companies and recruiters demand transparency from applicants, then "integrity" means they have to practice transparency, too.

18 May 2014

Window Panes versus Tiles

A lot of web and application designers follow the Windows 8 paradigm that uses flat, borderless tiles.


Change for the sake of change

I don't believe in change for the sake of change. "Change is good" only when the changes are good. When you want to go north and your bearing is 20 degrees, change is good when somebody says, "Let's turn left 10 degrees." But when somebody says, "Let's turn left 180 degrees," change is foolish. Good change is good. Change for the sake of following a fad out of Redmond is dumb.

Stepping backwards - Why not go all the way back to MS-DOS?

Flat, borderless tiles are boring; but that is subjective. Objectively, borders, especially three-dimensionally shaded borders, provide strong geometric shapes. By guiding the eye, they provide actual functionality.

Forward into ambiguity

The paradigm of imitating our three-dimensional world made GUIs more intuitive. The new trend makes graphics ambiguous: Is it a non-functioning picture or a functioning button -- make that, membrane switch? You shouldn't have to waste time experimenting to find out what's functional and what isn't.

Will it be up or down?

For notepads, tiles make some sense. Compared to PCs and laptops, notepads and smart phones have small screens and low processing power. The simplicity of tiles has its advantages.

Some day, notepads may outnumber PCs to such a degree that PC users will want the consistent look and feel.

On the other hand, notepads will gain in image resolution and processing power. Maybe the designers will return to the higher standard, and this ugly fad from Redmond will go away.

04 May 2014

Trusting the Project Team

Vikas Gupta asks on Google Plus, pretty well answering his own question:
How much can/should a Project Manager interfere in the technical details of a project? For e.g. If a developer thinks that xyz is the most efficient way of implementing a functionality, is it unproductive for the Project team to have PM challenge that beyond a limit? I personally think that challenging the team members is ok, but a PM must trust the technical skills of team members and too much interference may demotivate the team.. Thanks in advance for your expert opinion!
 Discussion Link April 30, 2014

Project-Aria replied,
It is rare that a PM is just a PM.
Usually the PM also adds value by bringing technical expertise. Now the question here is: does the PM have the expertise in technical area in question. If yes, then yes. If no, then interference may be a dangerous path.
I would also note that communicate is a 2-way challenge. It is also important to all team members, including experts, to be able to explain their ideas and convince others. It is important for the expert to be able to communication without hiding behind a expert-cryptic language.
Apr 30, 2014

I think Vikas stated it well and correctly. Early in each design phase, the PM can ask the team to consider his personal favorite solution. The design team should then compare the various options for each architectural element and weigh them against each other. The result is a trade study that weighs the trade-offs and makes an objective recommendation of the best solution.

Unless the decision is very close, the PM should leave the decision to the results of the trade study. If he does not, it can reflect badly on him.
  • It indicates that he did a poor job of selecting his team.
  • It insults the design team and, as Vikas said, demotivates them.
  • It may indicate that he failed to have the design team include his favorite option in the trade study.
  • It may indicate that he failed to properly define the design parameters.
  • It indicates subjectivity, a failure to rely on objective evidence produced by the trade study.
  • It turns the time and cost of trade studies into waste.
  • Failure to trust often results from projection; that is, expecting others to do what you would do. Therefore, it raises issues about the PM's ethics.
  • Overriding the results of a trade study can create an appearance of impropriety (for example, the PM appears to take a bribe from the selected vendor or subcontractor).
As Project-Aria stated, the PM may bring enough technical expertise to deserve the right to override the design team; but he had better have convincing technical reasons for his actions and had better own up to his mistakes that made his action necessary.

If your experience has shown you more reasons why a PM should or should not override the decisions of his design team, I'd like to hear from you in the comments.

30 March 2014

Training the Software Requirements Engineer

What are different type of training required for a Software Requirement Engineer?

The correct answer is, it depends. Software requirements training should fit with the type of project management used by your organization.

One type of training you don't need

Many people think a software requirements engineer should thoroughly understand programming and software engineering. Obviously, you should know something about the software engineering discipline, but knowing too much can destroy your ability to write good requirements. This happens for two reasons.

First, good requirements should ignore the technology (such as which platform or language is used). This is because requirements should not dictate the solution; they should only define the problem to be solved. Devoting too much study to the technology will bias a requirements analyst toward particular solutions. This makes consideration of alternate solutions more difficult for the design engineers.

Second, requirements elicitation is an art as much as a discipline. Managing stakeholders, conducting meetings, choosing elicitation methods, and choosing methods for representing information require strong skills in psychology and communication. Putting all your energy into learning programming languages and tricks will cost you on the human side. It would be as great a mistake as putting all your energy into market research. You need to know enough about programming to win the respect of the designers and to communicate with them, but your job is to build a bridge between the customer and the designer.

What should I wear? Well... where are you going?

Organizations that work with large systems that integrate multiple technologies tend to follow traditional Project Management and Systems Engineering methods. They use some variation of the Waterfall model, such as the V model.

For a high-level understanding of Systems Engineering requirements methods, I recommend starting with INCOSE's (International Council on Systems Engineering) Systems Engineering Body of Knowledge (SEBOK) and using the SEBOK as a guide to subjects for study. Also consider studying Model-Based Systems Engineering, one subset of traditional methods, and SysML, the modeling language used for MBSE.

Organizations that work primarily with software tend to follow Agile project management methods. In Agile environments, requirements engineers tend to go by the title Business Analyst. I recommend starting with the IIBA's (International Institute for Business Analysis) Business Analysis Body of Knowledge (BABOK) and using the BABOK as a guide to subjects for study.

Agile is a set of principles and not an actual method. I have asked for a recommendation for a book that describes the different methods (such as Scrum and Kanban) but have been told no such book exists; for each Agile method, you need to find a different book.

The requirements methods differ considerably between traditional and Agile. Traditional methods nail down requirements and then negotiate schedule and cost. Agile nails down schedule and cost and then negotiates, prioritizes, re-prioritizes, and drops requirements.

The two methods do share some of the same tools. I suggest studying Unified Modeling Language (UML). UML is not a language, but a set of graphical methods for defining requirements. The most commonly recommended book on software requirements is Software Requirements, 3rd edition, by Karl E Wiegers and Joy Beatty.

23 March 2014

Classes for Technical Writers / Communicators

Any suggestions for what further education pairs well with technical communication?
-- Nicholas
Ask the Right Question

Nicholas has asked the right question -- sort of. I don't think anybody can answer the question for him.
A technical communicator translates the Subject Matter Experts' (SME's) geek-speak into plain human-speak. Learning the SME's language will play a pivotal role in success. Even introductory courses in the chosen domain will dramatically shorten the learning curve once he lands a job.
The question omits any decision about the domain in which Nicholas will practice. When he chooses a direction, he will be better able to determine the answer for himself.
If Nicholas has not chosen a domain, yet, I would suggest that he visit his school's career office and the state employment office and ask, "What industries show growth potential for Technical Writers?" Once he has a list of, say, the top ten fields, he can consider which field(s) would most personally reward him.

After that, he can ask, "What subjects would best help me learn the language of the SME's in that field?"
Supporting Skills
An employee does not just sit down and start doing the job. Each job has supporting knowledge areas such as planning work, reporting activities, conducting meetings, and defining and adhering to ethics. A successful employee also looks ahead in the direction that the career and the profession will take. That adds soft skills, management, and industry trends to the list.
I will name two of the most important skills Nicholas could add to his quiver.
First, the most important SME in anybody's career is the boss. Learning about project management (I suggest PMP Exam Prep by Rita Mulcahey) will help Nicholas:
  • Understand how he can support his manager's success
  • Learn more about organizing his own work
  • Start his climb up the career ladder
The knowledge areas defined by project management standards can also serve as springboards into further studies.
Second, the ability to visually model processes and information would help Nicholas in any industry. To that end, he should familiarize himself with the Unified Modeling Language (UML). An Internet search will turn up plenty of tutorials.)
UML is not a language (not in my vocabulary, anyway), but rather a set of graphical styles and standards for defining and illustrating relationships between entities and for defining the processes in which entities interact. If Nicholas works in the software field or supports business processes, he will probably need to understand UML, anyway.
Basic Life Skills for Success in Any Technical Career
People normally associate project management with management and producing products, and they associate UML with software engineering, systems engineering, and business analysis. However, the set of tools these two topics would give Nicholas, and the ways of thinking that they teach, would be invaluable in almost any domain. He can study those areas while thinking about the industry he wants to work in.
"Professionals" distinguish themselves by continuously and independently learning. Schools lead students through semi-standardized curricula, but professionals write their own curricula. Nicholas should plan his future studies but bear in mind that:
  • he will continuously update that plan, and
  • he does not have to do all his studying now.