Search This Blog

Loading...

28 February 2015

The Black Hole of the Agile World: Systems Thinking

Agile fanatics (excuse me: practitioners) love to do things incrementally.

That's OK for their little worlds in which there's no heavy lifting to do, but it's fantasyland for many projects.

Take, an example, the design of a new car. Sure, you can break the car into systems -- chassis, body, safety package, motor, and so on. Waterfall does that, too, but let's consider the airflow over the body. The airflow is affected by the whole assembly. Every part affects the whole. You can't just design a fender in isolation and say, "Looky, looky, I've delivered value!" No, you've delivered an irrelevant piece of scrap.

In any course on Business Analysis, the importance of a unit on Systems Thinking cannot be overemphasized because the Agile world has completely forgotten its value. 

Before the 1990's, there was a role called Systems Engineer.

That title is still around, but the job is not. At least, the job has become a rare grain of wheat a vast field of tares.

A Systems Engineer had many skills of a project manager, a BA, a Systems Thinker, and a cross-disciplinary engineer, all rolled into one.

Along come companies such as Microsoft and Cisco, dropping the qualifying word from titles such as Network Systems Engineer, Software Systems Engineer, and Server Systems Engineer. Suddenly, every engineer, analyst, and administrator is a Systems Engineer.

True Systems Engineering jobs have become needles in a field of haystacks, and systems thinking has almost been forgotten.

Thousands of Systems Engineers lost their jobs due to decimation of the US Defense sector in 2009. They still find three strikes against them:
  1. Transitioning to a different job category such as Project Management or Business Analysis
  2. Getting a foot in the door of a different industry (other than fast food)
  3. Living in a job market where all the growth is in part-time service jobs such as flipping burgers.
Hiring managers would do well to consider bringing in experienced cross-disciplinary, systems thinkers. It would not take much training to bring them up to speed in new roles such as PM or BA.

Have you ever thought of a project as a system of people, or a product as a system of technologies? Systems Engineers do that instinctively, and such integrated systems thinking could prevent a lot of headaches for maturing companies.

Now, if you'll pardon me; I need to clean up a spill in aisle five.

Models versus Prototypes

What is the difference between models and prototypes?

Some people are confusing prototypes with models. Most of the examples given in other comments are engineering models (and they are valuable). A prototype is one type of model.

1. Before prototypes, you have engineering models. For example, a wireframe diagram just sits there. It's not a prototype, but it's still valuable. On the other hand, you might have a program with a generic GUI. It might be fully functional, but without the semi-final GUI, it's still not a prototype.

2. A prototype is the first (proto-) thing of its class (-type). Prototypes would include the Beta version of a software product or a widget built in a shop.

3. After the prototype, you have the production model. That's the model you sell in the store, the one you send out samples of, or the one that comes off the assembly line.

Off my soapbox and on to the questions:

1) Does prototyping have to be studied by external institution?

That depends on the product. Suppose you work in IT and designed a SharePoint site for the Engineering department. You will want Engineering to see models and then the prototype in order to identify the refinements that will take your product from "Gets the job done" to "Delights the customer." If your customers are other companies: Yes, you want it to be reviewed by them. And if you are subject to regulation by government agencies and licensing authorities, it's far less expensive to get their approval early than to get it later.

2) What information can we get from prototyping? Does the information we get show us the quality or preference or anything else?

Quality means, "how well the product meets the needs." If showing the prototype to the customer helps ensure that it meets the customer's needs and preferences, then the feedback helps to ensure quality.

For example, before converting Office from drop-down menus to ribbon bars, Microsoft probably let hundreds of users play with it. They would have found out preferences for how many icons to fit in a frame, which functions to place in the ribbon, which functions that were now hidden people would have to go hunting for, and how much they'd have to spend on marketing to convince people to accept the transition.

From a systems perspective, when Microsoft converted Office from the old file types (.doc, .xls, .ppt) to the new formats (.docx, .xlsx, .pptx), they used prototypes to investigate compatibility between programs.
 
For example, could you still import a section of an Excel spreadsheet into PowerPoint? Could you still save a Word document to Open Document Format or RTF files? Will Word and Excel compete for the same memory space and slow down or even crash the computer? Will the new version of MS Access have a reduced startup time?
 
Even after that, Microsoft still puts Beta versions in the hands of thousands of users to find the problems nobody thought to test for.
 
You can't answer such questions with confidence until you build working prototypes to test and experiment with.

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.

However,

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.