enweave

Thursday, June 7, 2012

Assumption = Question: Question Assumptions

In the domain of Program and Project management, challenging assumptions consumes much of our time and attention for a very basic and very sound reason. The death blow to most failed efforts is, in one way or another, traceable to an invalid or faulty assumption.

An assumption is essentially an unanswered question. Answer them early and often during the course of any effort and the risk of failure plummets. In addition, the risk of starting something doomed from the beginning is minimized.

Despite saving huge amounts of effort, resources, and money, don't expect a stress-free ride down the Assumption Trail. Many people react strongly when their assumptions are questioned. It's tense.

Friday, April 13, 2012

Breaking New Ground: Ditch Requirements

In an environment of "knowns," where standards exist, we can talk about requirements. Where we are facing the unknown--new territory--where no standards exist, there are no requirements so we think and act in terms of assumptions or hypotheses.

Hypotheses are proposed answers formulated as questions.... Assumptions held as provisionally true until proven (tested). Put another way, hypotheses are proposals that explain how things might work. Whether we build radically new, ground-breaking technology or start radically new, ground-breaking business ventures, our work is primarily based on hypothesis and their validation, not on meeting requirements.

Hypothesis are validated by testing. Hypothesis and validation are inseparable. Constantly testing hypotheses, adapting to the results, formulating new hypothesis, testing again, and so on is the routine.

The process is iterative. Progress is also incremental (results appear in stages). All progress is real progress; tested, validated, proven.

Validated learning is the basis for measuring progress.

"We believe ____________ (hypothesis)," is always paired with:

"We know ____________ (hypothesis) is right when we see ________ (tangible result).

There is an alternative validation approach: Proof that the hypothesis is incorrect. In some cases, this may be a better (quicker, cheaper) approach.

"We know ____________ (hypothesis) is wrong when we see ________ (tangible result).

Either way, there is some tangible result from testing--evidence of validated learning. In the case of technology, positive results may mean working code or a functional prototype. For a new business, positive results may mean sales or funding. Negative results may mean avoiding a long, costly run down a blind alley. Validated learning, in either event, is the means by which we understand, track, and measure our progress.

A working method for this approach might look something like this:

Discover (identify and document) assumptions
Formulate assumptions as hypotheses
Determine validation criteria (qualitative and quantitative) based on the smallest thing that can be done or built to test
Prioritize hypotheses for validation based on risk (more unknown = higher risk)
Start validation of higher risk items first (high risk = high priority)
Validate, test, acquire feedback
Rinse and repeat

When in new territory, every design decision (or business decision) is a hypothesis. Know the assumptions, state them clearly, share them; test and validate. Build continuous testing and continuous feedback within your team.

Understanding that we work with hypothesis leads to better management of process and outcome.

Thursday, April 12, 2012

The Struggle for Success

In the world of projects, we constantly struggle for success and one of the longest, most difficult, and time consuming battles we face in that struggle is defining what we mean by "success."

Over many decades managing a wildly diverse collection of projects and project types for clients large and small, one way of defining what success means has proven most useful. It can be described in the form of an equation.

Success = Results - Expectations

Results (functional, non-functional, quality, and more) and expectations (financial, technical, political, etc) are so important that, in our human attempt to "manage," we try to define them in greatest detail as the first step in starting a project. We "set them in stone" and then expect great kudos when we achieve them. But, we are fully human, and when that approach fails to achieve success and those kudos never appear, we always ask, "Why?"

The idea that clients, customers and users can know everything about what they need 6-9 months before they get their hands on it is simply a fallacy for most businesses. On the contrary, it is the act of getting their hands on it that defines and refines those needs.

So, the way to success lies not in fallacy or fantasy but in reality... Putting real, working pieces of the project in the hands of users constantly and adapting based on their continuous feedback. Expectations and results, therefore, are aligned in both an incremental and iterative manner throughout the project.

Wednesday, April 11, 2012

W.A.I.T. and Listen

For those claiming a leadership role at any level as well as those carrying the tag "consultant" after their name there is an acronym worth burning into your brain: W.A.I.T. "Why Am I Talking."

We have a word--several, actually, and none are "family friendly" sobriquets--for people who consistently fail to understand that nothing they will ever say is as important as that which they will hear. Some of the more gentle terms are: Overbearing, arrogant, meddling, pushy, and offensive.

Leading and mentoring (the heart of any consultancy) requires a different approach... a different personality type and, it's not just about "style," it's about substance. Ask questions (intelligent and pointed), listen carefully--small, subtle things can be of great importance (care about the person's ideas), then respond appropriately (be social and carry on a two-way conversation).

The point is to connect, not dominate; learning is a mutual activity. You can not expect anyone to learn from you if you can not learn from them.

Monday, April 9, 2012

Uncertainty Principles: Forget the Assumptions, Get the Facts

Uncertainty is something we all deal with in both our personal and professional lives and is frequently mis-characterized as risk. However, lack of knowledge is not technically a risk. Since we identified a key piece of information that is currently lacking from our critical knowledge base, it is a certainty, not a risk. Uncertainty should be treated as such instead of as a future event. Fortunately, acquisition of specific knowledge always reduces or eliminates uncertainty so managing lack of knowledge can be straight-forward.

The first step in managing uncertainty is admitting we can not see (or plan) beyond the first point of uncertainty in a project. Assuming we can, on the other hand, leads to massive risk. Relying on unproven assumptions is a recipe for massive, whole project re-planning, and the resulting (sometimes massive) re-work required to get the project back on track. And, even then, that "track" realistically only runs as far as the next point of uncertainty where, if assumptions prove wrong, we start all over again. Admitting we can not see beyond the first point of uncertainty in an effort, however, leads to reduced risk across multiple dimensions.

The to key to successfully managing uncertainty lies in planning only to the short time/effort increment required to obtain the next critical piece of information. Then, make adjustments (adapt) only after the new knowledge is acquired in planning for the next point of uncertainty. In other words, incrementally plan the effort based on acquiring key pieces of information at the point they are actually needed (just-in-time), then adapt and plan the effort to the next point of uncertainty.

Wednesday, April 4, 2012

Data Sea; Data Do

We live and work in a sea of data trying to envision, understand, and plan for the future. That data, however, by its very nature is primarily about the past.

In order to make use of data in ways applicable to the future, we apply theories. These theories are often referred to as predictive models, which are frequently integrated into decision models along with other theoretical constructs such as descriptive models. The process of applying theories or models with the future in mind is predictive analysis.

This kind of analysis is employed daily across a diverse collection of organizations relying on disparate and common data sources from both internal and external sources. Its most widespread application lies in organizations such as actuarial science, financial services, insurance, telecommunications, retail, travel, healthcare, pharmaceuticals, and other fields including portfolio and program management.

Using data coupled with theories or models to predict the future is more than simply "common," it is ubiquitous and the foundation for strategic, tactical, and operational processes in our governments, commercial enterprises, and other organizations, as well as in our personal lives on a daily basis. We humans are constant predictors but our results are less than consistently predictable.

Much attention is focused today on data: Big data; a sea of data. Obtaining more and more data is becoming easier and easier and it's coming at us faster and faster. Yet predicting the future is not appreciably more accurate today than ten years ago. Simply acquiring more--even more accurate--data isn't necessarily translating into better results. Why?

Even the most accurate data (historical, current, or real-time), even in overwhelmingly huge amounts, when viewed through the lens of a flawed theory or model, becomes distorted, twisted and useless. In other words, perfect data produces imperfect results when analyzed using even slightly imperfect theoretical constructs.

At least as much--or more--attention is needed on envisioning, creating, testing, and implementing valid analysis techniques and models as is given to data acquisition. Without advances in models, constructs, and analysis techniques, acquiring more data leads to erroneously high levels of confidence but no greater accuracy in predictive results.

Tuesday, April 3, 2012

Defining Deliverable Outputs

A "deliverable," in project management, is an object (tangible or intangible) created by a project for delivery to an internal or external client. A deliverable might be a report, video, document, system upgrade, process change, any other product or service or piece thereof. Activities (work) are connected with deliverables.

Creating a deliverable is a process. What is needed to produce the deliverable are its inputs. What the deliverable produces--what it is created to do (functions, forms, work) are its outputs.

While most of us are good at naming or listing deliverables, we are not as good at defining their outputs. Without well defined outputs, deliverables can not be tested or integrated well and that invariably leads to rolling out a poor solution to the client.

Defining deliverable outputs is a key step toward transitioning projects that meet expectations.

Monday, April 2, 2012

A deadline is a deadline, right?

No, not entirely; there are at least two different types of deadlines: Hard and soft. In project management terms, a "hard" deadline is on the critical path and missing it has serious, perhaps fatal, consequences to the project. A "soft" deadline is still a deadline but not on critical path and without those dire consequences if missed. There are other distinctions as well but prioritizing deadlines in any manner whatsoever is so rare as to be nearly non-existent.

Understanding and managing both personal and organization priorities is critical to success. Not doing so is an early (very high probability) indicator of disaster; failure. Prioritizing deadlines for yourself and your team is a big step toward staying on track.

Monday, March 5, 2012

Leaders and Managers

At one time--quite a few years ago now--as a contractor in the construction business with several teams of hard-working people, lessons about improving the way people come together to accomplish goals was a daily part of life. It still is today but one such incident from that earlier time stands out with great clarity, a memory and line of thinking that has only grown more important with the passage of time.

Two new employees (first day on the job) are excavating around the perimeter of the job site one afternoon. Due to terrain and existing obstructions, they are manually excavating a trench with shovels and picks. Eventually, the trench becomes a footing for a small stone retaining wall alongside exterior concrete walkways. Even standing on the other side of the job site, the grumbling and muttering between the two excavators along with their frequent questioning stares around the area at the activity of others is a sure indication of some issue.

The Supervisor (also a new employee) and I are discussing plans and logistics in a "quiet" spot. The drama implicit in the actions of the two newbies grumbling their way through the sticky, black clay is demanding more and more of my attention. After we decide the planning and logistical questions, I ask the Super how the two new employees are doing. He shakes his head, lowers his eyes, staring soulfully at the tip of his boots, saying, "I just don't know. They seemed sharp enough--and, maybe they are. They claimed they were ready to work but... well, they might not pan out."

"You want me to have a talk with them," I quietly suggest?

"Sure," he says looking up, "Maybe you can talk some sense into them."

So I make the rounds of the job site, wandering a bit and casually talking with crew and subs while incrementally approaching the two shovel wielding newbies. When I reach them, I introduce myself, shake hands, and ask them how their first day is going.

Their initial response is a rather dismal, "OK, I guess," without any eye contact. To continue the conversation and draw them out I ask, "What are you building here?" pointing to the excavation.

The answer is stunning. They both simultaneously exclaim, "That's the problem: We don't know!"

Yes, that is certainly a problem: Sound familiar?

It happens a lot in every area of human endeavor. Instead of bringing new people on board through the sharing of vision, goals, and desired outcomes, a different approach is taken. One that involves unilateral command, disciplinary action, and micro-management. It goes something like, "Dig a hole from point A to point B at a depth of C with a width of D. Get it done today or don't come back tomorrow."

That is a recipe, as a manager, for long fruitless hours, stress, heart attack, poor outcomes, and failed projects. A machine might be "managed" in that way but people must be led.

So, I gave 30 minutes of time to the new employees discussing our company, our organization and the project we were working. Not "laying down the law," instead having a frank and open discussion. When they understood the basics and questions were answered, we reviewed the details of this specific excavation. We pulled out plans and discussed what the client wanted, where, and how we expected to make it happen. I showed them where what they were doing today fit into the plan, why it was so important, and how we were depending on them to achieve the desired outcome.

They "got it." Done.

When they understood the goals and had a clear picture of the outcome expected, they went back to work without grumbling, without questions, and continued to do excellent work for the remainder of the project. The excavation was finished that day ahead of schedule and without any need for rework or any further conversation.

When I explained the situation to the Super and showed him how it worked on subsequent occasions, he became a skilled mentor in bringing people on board and a highly valued member of the organization. The two excavators, last I heard, were quite successful as owners of their own businesses.

People who are talented and capable, people who are committed, engaged, and on board with the goals will self organize to achieve those goals.

Thursday, March 1, 2012

Planning Value

The value in creating plans is not found in blindly following them but in using them as tools to intelligently and proactively manage inevitable change.

Wednesday, February 29, 2012

Inevitable

Change is both rapid and constant. Proactively embrace that fact in ways that drive improvement.

Creating plans, process, and methods that address the inevitable changes of circumstance may seem daunting. However, to do otherwise is to expect that circumstances change to fit plans, processes, and methods which makes disaster inevitable.

Saturday, February 25, 2012

Why small is sometimes big

‎"Starting small" doesn't necessarily mean doing small things. Starting step one of massive, complex, daunting goal broken down and prioritized in manageable chunks is "starting small." Starting is the key.

Friday, February 24, 2012

Intelligence, talent, and genius

Almost anyone with intelligence and some talent is able to complicate matters; arrive at a solution that is bigger, more complex than the problem. There is, however, a world of difference between intelligence, talent and genius. Some portion of genius is required to solve problems in ways that simplify, rather than complicate, the outcome.

Monday, February 20, 2012

Risks and Obstacles

A risk is not an obstacle; it hasn't materialized. Equating risks with impediments or barriers is placing a mental obstacle of our own construction directly in our forward path.

Tuesday, October 4, 2011

Hyperbole

Hyperbole is the downfall of requirements, proposals, and status reports.

For most business endeavors, too much success is just as disastrous as complete failure.

Monday, October 3, 2011

I am a project manager

I am a project manager: At its most basic, that means knowing "how" to get things done. That "how" stands, primarily, for "process." Many, but not all, my thoughts here share that focus on process.

I am deeply involved in both program and portfolio management. That means not just"how" but "what" and "why" and "when." "What" is to be accomplished could be referred to as "the ends." "How" the thing is accomplished, then, refers to "the means." "Why" is the strategic framework. "When" is about organizing the various "what's" into a logical sequence of events.

Standing outside the context of business and business technology I often speak to social, political, or cultural issues. Not here on this forum but on others. We (myself along with other project managers) have something to share; it's important. Important in the context of business, technology, and important in the larger context of getting things done in life.

Regardless of how carefully and rightfully the vision is crafted, goals defined, and success factors enumerated, if the methods, techniques, processes, and people employed are imperfect, those imperfections become realized in the outcome. In a sense, the end becomes the means.

We never achieve greatness (success) through flawed means. The most brilliant strategy is brought to naught by tactical failure. No amount of individual effort can overcome it; no amount of shiny rhetoric can gloss it over; neither advertising nor marketing can salvage it.

Posted by:

Thursday, August 25, 2011

Quotable: Disaster

Disaster Quotes Page 2 - BrainyQuote

"If a sufficient number of management layers are superimposed on top of each other, it can be assured that disaster is not left to chance." ~Norman Ralph Augustine

Friday, April 23, 2010

Why do projects succeed?

We've all seen "top ten" lists and read "why projects fail" rants. Here, we've discussed project failure as well as on Twitter #pmot, and LinkedIn. It may be (creating another "top ten") the number one item of discussion among project professionals. If not, it's certainly near the top.

Projects fail for every reason... all reasons. At some level there may be value in knowing what all those reasons are but--let's face it--when the list is written, it is everything.

Question is: When we have the list in front of us, what do we do with it? How valuable is that data? How do we know which particular item on the failure list is applicable to any given project... and especially the project we're starting now?

A lot of effort and analysis can go into crafting answers to that question. The answers are largely project specific. The answers are treated like any other project risk. If we're good at risk management, that effort might be useful. If we're bad at it, the effort is wasted.

The biggest obstacle (e.g. risk, failure point) we will face in a project is the one we did not anticipate. If we're good at handling unanticipated obstacles, we may go on to succeed. If not, we won't. The list won't help if the biggest threat is something not on the list.

So... Why do projects succeed?

That may be the more important question. The answer may lie in how well we handle unanticipated events.

Thursday, April 22, 2010

Similarity and Success

In my consulting work withing large, complex organizations, I began to realize remarkable similarities among organizations. In fact, there were more remarkable similarities among successful, large organizations than remarkable differences.

In smaller organizations I found this not to be the case at all; quite the opposite. The differences among younger, smaller organizations and particularly between them and their larger cousins are considerable.

After decades of monitoring innovation, progress, and outcomes within businesses of all sizes, I came to understand that the successful outcomes were more closely related to those similarities than the differences.

At the organizational and meta-process level, the more attributes you have in common with other successful enterprises, the higher your chances of success.

Tuesday, April 20, 2010

People or Process

Committed, engaged, talented people may succeed despite deeply flawed processes but it is incredibly difficult and they burn out rapidly. Even the best--world class--processes may deliver flawed outcomes without committed, engaged, talented people. It is not "one or the other," it is "both."

Monday, April 19, 2010

Process Improvement Opportunity

Common business plan: Hare-brained Idea > Foregone Conclusion = Instant Wealth

Friday, April 16, 2010

Contact with the enemy...

Planning is often followed by blind adherence to a plan. The first leads to success; the second to failure. Plan accordingly.

Friday, April 9, 2010

Friday Epiphany

Friday Epiphany: The biggest obstacle you will face is the one you never expected.

Engage

Talk isn't cheap when it leads to understanding. Engage.

Thursday, April 8, 2010

Complexity and risk

As system complexity increases, predictability--even of a small change--decreases while probability of its harm increases.

Monday, April 5, 2010

People Problems

"People problems" are caused by people, not technology. People are also the solution.

Wednesday, March 31, 2010

Be careful who you wish for...

A group -- no matter how well formed -- of managers and sales people nodding agreement to requirements should not make you feel safe.

Tuesday, March 30, 2010

Fill the gap

Projects fill gaps between organizational goals and current status. If not, question why.