Communication pragmatics

A recent book review on the pragmatics of communication highlighted three ideas I'd not thought a lot about, but perhaps I should:

In the presence of another person, it is impossible not to communicate: This point is so obvious as to often be overlooked: silence amounts to communicating that one does not want to communicate. [Think about this as you contemplate virtual situations ... communications may not survive all that well]

Every communication has two aspects to it: ..... what matters is not only what is said, but how it is said and the context in which it is said.

The relationship is defined by how participants perceive a sequence of exchanges: A dialogue consists of a sequence of exchanges between participants. However, the participants will punctuate the sequence differently [In other words, the value of communications is changeable by sequencing and cadence]

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

IT technology Top Ten

Michael Cooney has posted Gartner's Top Ten for IT technology:

The Top 10 Trends and their impact, briefly include:

1. The evolution of virtualization: ... virtualization will ultimately drive more companies to treat IT [more] like a business. [Perhaps, but virtualization will more likely continue to change our idea of borders and boundaries, making them more virtual than real]

2. Big data, patterns and analytics: Unstructured data will grow some 80% over the course of the next five years, creating a huge IT challenge.

3. Energy efficiency and monitoring: The power issue has moved up the food corporate food chain.... An average x86 server that is turned on, but idle, will draw upward of 65% of its nameplate wattage, for example. 

4. Context aware apps: ...  context-based computing will go beyond the business intelligence applications and truly make a unified communications environment possible .

5. Staff retention and retraining: Loyalty to one company is not a quality found in new workers.

6. Social networks:    Ignoring social networking is not an option

7. Consumerization: The key trend here is the fact that new application types will be developed to address mobile users but they won't be desktop replacement applications. 

8. Compute per square foot:  ... average server performance can move from today's paltry 7% to 12% average to 40% to 50%, yielding huge benefits in floor space and energy savings. 

9. Cloud computing ...the biggest benefits of cloud computing are built-in elasticity and scalability.

10. Fabrics: Gartner defines this infrastructure convergence as: The vertical integration of server, storage, and network systems and components ...

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

That velocity thing

Jim Highsmith, a guru in the agile space, has an interesting post on that velocity thing. Velocity, you will recall, is the agile name--originally an XP name--for the rate throughput can be delivered to customers, or, if not delivered to customers, the rate at which throughput--finished deliverables--can be queued for rollout according to some rollout strategy and workflow.

 

Now, the idea of throughput is not an agile thing, per se. Go back to the mid-1980s to Eliyahu Goldratt's Theory of Constraints (TOC). TOC is all about optimizing at the enterprise or project level  maximum throughput to customers. Velocity was not a Goldratt idea, but Eliyahu certainly focused on cadence, using the metaphor of the drum-buffer-rope.

 

Of course, project managers may know Goldratt for his theory of the "Critical Chain", a risk management strategy for insuring on-time delivery. Critical chain is an outgrowth of TOC, and it's Goldratt's idea of how to put some of his throughput management ideas into the body of knowledge for project management.

 

I digress--as often happens here at Musings--so back to Highsmith's lament: he says that having positioned velocity as a calibration metric on team performance, project managers should not then count on teams to achieve the predicted performance because a emphasis on performance may then trump quality, the ultimate goal of an agile project. Even the customer may become part of the problem. In his words:

 

• Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.
• Focusing on volume detracts from the quality of the customer experience delivered and investing enough in the delivery engine (technical quality).
• Giving the product owner/manager complete priority control makes the problem worse—we have gone from customer focus to customer control that further skews the balance of investing in new features versus the delivery engine. 

Dean Leffingwell makes a similar point in his book "Agile Software Requirements: Lean requirements practices for teams, projects, and enterprises". He says that if the velocity metric is turned back on the team by managers, the team will do one of three things:

1. Practice continuous improvement to meet management objectives
2. Sacrifice quality in the name of speed, or
3. Sandbag estimates to create velocity buffers

Of course, my point is not to use the metric to amp up productivity, (that's Highsmith and Leffingwells's fear) but to use the metric as an expectation suitable for estimating. If you can't estimate, what's the point of the metric?

And, they've got a point about sacrificing velocity if quality is the ultimate driver. But that puts 'better' as the nemesis of 'good', and puts in question the real advantage of agile that, in my mind, is delivering best value (which could be different from best quality, though I've not thought that all the way through).

And, you ask, what's my idea of best value? Simply put:

 

• Best value is the most valuable outcomes achievable, as judged by the customer, for the investment available from the sponsor
• Best value is the most bang for the buck, a best compromise of scope and quality in context of fixed investment and a critical need date.

By the way, I'm all about throughput. You really can't do a decent job as a agile manager unless you can benchmark for throughput and then hold teams accountable.

 

The issue is: accountable for what? I say the answer to Highsmith's issue is to get the iteration backlog right with the customer and the project team at the point of release planning. Once planned for best value, then bring on the throughput!

 

 

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Happy holidays to all!

Photo

On the eve of Christmas

Best wishes to all for the holidays!

Photo

Quantum computers in the offing?

... the team has demonstrated that it is possible to take photons from two disparate sources and render these particles partially indistinguishable ... [suggesting] in principle that they can connect various types of hardware devices into a single quantum information network.

This bit of quantum news was recently reported by the National Institute of Standards and Technology (NIST) on their blog. And, actually you could say it's a breakthrough that might lead to quantum computers and a whole new era of amazing computational power.  Who knows where that might lead?

I can't wait to hangup the silicon laptop for a photon computer!

Bookmark this on Delicious

Agile and architecture

If you accept this fact—that the choices you make today will most certainly be wrong in the future—then it relieves you of the burden of trying to future-proof your architectures.

—Richard Monson-Haefel, author of 97 Things Every Software Architect Should Know

It continues to amaze how some agile advocates fail to recognize, and even deny, that when you put together something as simple as two objects, you've created architecture (definition: a description or specification of behavior, appearance, structure, and relationship of and among components).

Thus, when some agilists say they need not concern themselves with architecture, or that it is not all that important, I wonder what planet they are on. Attention: even if it's not written down, or put to powerpoint, a system (two objects, or more) has architecture, and their behavior jointly may well be important and worthy of evaluation.

And yes, I'm aware of this agile principle: "The best architecture, requirements, and designs emerge from self-organizing teams", though I'm not alone saying this principle is decidely limited to the small bore and fraught with scalability issues.

My attention was drawn to a posting by Phillipe Kutchen entitled "Agility and architecture koan" for two reasons:,

1. I did not know what "koan" means; I thought I might find out.
2. He quote a truly mindless statement from a LinkedIn group: “Self-organizing teams can decide everything by themselves. So they don’t need an architect.”

• The former means paradox, or non-sensical statement or question
• The latter is just mindless, but to give the widest possible latitude, perhaps the author was referring to a dedicated position called "architect" and not trying to say that team members should not be architects, or worse: there's no architecture per se.

Anyway, I am in the Kutchen school. In a book I wrote about agile in enterprise projects, and in an article Kutchen wrote for Software (an IEEE publication), Agility and Architecture: Can They Coexist?, we both expound on the obvious: architecture is a matter of context, project context, but all projects and all systems possess architecture, whether you want it or not.

And, of course, even unabashed and credible agilists like Dean Leffingwell, author of numerous well regarded books and articles on software practices in general and agile practices specifically, says that as a project becomes more than the scope of one team working:

For developers, architects, and businesspeople who have experience building large-scale systems and portfolios consisting of systems, products, and services—with the extensibility and scalability a successful solution demands—a solely emergent architecture is counter to our experience. We know that some amount of architectural planning and governance is necessary to reliably produce and maintain such systems. Individual teams, products, and programs may not even have the visibility necessary to see how the larger, enterprise system needs to evolve. It can’t simply emerge. Something has to tie it all together......


Even minor, system-level redesigns can cause substantial rework for large numbers of teams, some of whom would otherwise not have to refactor their module. It is one thing for one team to redesign their code based on lessons they have learned; it’s quite another to require ten teams to do so based on another team’s lessons learned.

And no less an eminence than XP's Kent Beck writes:

Architects on an XP team look for and execute large-scale refactorings [and] write system-level tests that stress the architecture....

While the system is little, the architect makes sure the system has just the right little architecture.

In another space, Computing Now, Maurizio Morisio provides a half-dozen links to reputable thinkers about the role of architecture, architects, and the intersection with agile methods.  Take a few minutes, and read all about it!

Source:
Chapter 20 "Agile Achitecture" from Dean Leffingwell(2010). "Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise",  Addison-Wesley Professional. Kindle Edition

Chapter 10, "The Whole XP Team" from Kent Beck (2004)"Extreme Programming Explained: Embrace Change" Second Edition; Addison-Wesley

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Risk or Opportunity management?

What's going on here?

• Venture capitalists put their money at risk and successfully backed a start-up called Facebook
• Jon Corzine took a risk on European soverign debt and went bankrupt, but John Paulson and George Soros took similar risks during the financial crisis and made billions.
• General Bernard Schriever couldn't risk a failure of the fledgling ICBM program, so he developed the Titan and the Atlas concurrently using different designs
• General Samuel Phillips couldn't risk missing a presidential schedule for the moon landing, so he ordered an unprecedented test program to flight test the Apollo multistage rocket as one stack rather than test each stage independently.

Are these examples of risk management, opportunity management, or some combination? And, by the way, is there a difference, and even so, does it matter?

In other words, is "taking a risk" risk management, or opportunity management?
And, is this posting about counting angels on the head of a pin, or is there a worthy point to be made?

Actually, I say there is, in this respect:

• Taking a risk is usually understood to mean taking advantage of an opportunity, an event out of the ordinary, or an event that is off the strategic path. If it works out, the "risk takers" get rewarded, in some proportion to the risk taken: more risk, more reward. If it doesn't work out, either the risk takers are punished, or at the least not rewarded.

• Managing risk is usually understood to mean preventing an untoward outcome that might derail a course of action or unfavorably impact an outcome.  If it works out, the risk managers are rewarded according to the project success, not according to the impact avoided. In other words, successful failure avoidance is not rewarded directly; reward is only indirectly through whatever incentive was placed on project success.

And, in the project domain, project managers, as a matter of routine, are expected to be successful. Rewards are modest, given the expectations. Stakeholders who "take a risk" and are successful are usually much more handsomely rewarded.  This is not a sour grapes argument, just a discourse about risk and reward vs. opportunity and reward.

Dr Edmund Conrow is an academic, an author, an advisor to defense programs, and a skeptic of opportunity management (at least in the project domain, and domains are important because some concepts don't port well between domains).

But, Conrow provides us with a simple but useful definition of opportunity management: "In simple terms, it's a change in direction of the status quo that will leave us--we believe--in a better place than is currently anticipated". And, he says, to purse an opportunity requires "....allocation or reallocation of resources...".

I agree with Edmund: opportunity is a change in direction; and my corollary is: risk is a threat to not changing direction.

In an article written in 2008 in the DoD publication AT&L for March of that year, entitled "Opportunity Management", Conrow disses the idea that risk and opportunity are more or less opposite sides of the one idea that there are events in the life of a project that will push it off track--risk being a unfavorable outcome, and opportunity being a favorable outcome.

Conrow is not an opportunity denier; far from it. He advocates opportunity management in the sense of a search for alternatives, but not after the baseline is committed. Once committed, the baseline is to be managed to hit its targets until some formal baseline change is initiated and approved.

But, is a planned make/buy decision that is deferred until circumstances are more clear an exercise in opportunity management or risk management?

He sets aside, rightly so in my mind, the idea that project managers deliberately ignore four opportunity possibilities advanced by opportunity advocates, saying most competent managers maintain 360 awareness of these types of opportunities:

1. Opportunity to improve the baseline when there are otherwise no risks
2. Opportunities that are the inverse of a risk to baseline
3. Opportunites that arise from the interactions of risks to the baseline, and
4. "Pure opportunites" unrelated to, or different from, the baseline plan

Bottom line: taking a risk and managing risk are different; they both belong in the project manager's domain. The former is a change management agenda; the latter is a baseline maintenance agenda. There's room for both, as there should be.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Voice of the customer

General James F Amos, Commandant of the US Marine Corps, has taken on the acquistion bureauracy since assuming command of the Corps.

At issue: favored acquisition programs for modern weaponry for the Marine Corps, and to some extent, a rescue of the Marine's mission, now under fire as an unncecessary second land army.



So, when I see in a recent interview where Amos says that he had appointed himself player-coach (his phrase) on a number of troubled projects, I had to read further.

A couple of his thoughts that caught my eye:

 Math decisions are easier than thoughtful decisions based on strategy and what's best for [the mission]

[To his professional acquisition team]: You're telling me it will take 14 years to get the requirements right, develop this thing [a new amphibious vehicle], source select, test, and then field initial capability? You're crazy!

And of course he's right: if we've waited 14 years for major solutions, like the mine resistant reconnaisance vehile developed for Iraq, we'd be five years yet getting it.

Perhaps General Amos should take a page from USAF General Bernard Schriever, the father of modern program management and system engineering, who, the post war 1950s, pretty much invented how to do military weapons programs (the exception being the WW II program for the 'bomb', a program that Schriever did not participate in). In a recent book, "A Firey Peace in a Cold War: Bernard Schriever and the ultimate Weapon", by Neil Sheehan, General Schriever's acquisition methods are explained in a great tale of the Cold War.

His idea is to put system engineering on the front burner, work quickly with prototypes, develop high risk ideas with multiple concurrent solutions, drive hard for the initial operating capability, and don't let better defeat good. In other words, don't let strategy, or strategic purpose starve innovation. Be prepared to accept opportunity as perhaps a better way.

Perhaps, Schriever was the original agilist!

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Risk management -- what a concept!

While the firm encourages risk-taking ....., it also empowers its risk managers — at other firms considered the back office — to constantly challenge even the most senior leaders to keep them from going over the cliff.


"98 percent of my time thinking about 2 percent probabilities.” That is not something you hear from most .... chief executives

Andrew Ross Sorkin

What a concept: bring risk management out of the back office!

Now, here's the problem with that: Risk management is about avoiding failure; incentives reward creating success. It might look like this is two sides of the coin, but they really aren't. Project managers are told "it's your job" re the latter; sponsors and stakeholders are in the driver's seat for the former.

So, senior management follows the money. No news there.

But of course, we are told: risk and opportunities are both part of risk management. But are they really? RM has its own process; opportunities need not apply. Opportunities are managed either in a portofolio, strategic plan, or in a project's change management process. The overlap with RM is coincidental at best.

So, if there firms that put RM on the front burner, I say: more power to you!

Bookmark this on Delicious

Complexity anyone?

John Biaz, a mathematician rather than a project manager, asks some provocative questions from time to time that are of interest to us. The latest in his post on complexity:

What can you do with just a little information?

• Bill Gates’ first commercial success was an implementation of a useful version of BASIC in about 4000 bytes;

• The complete genetic code of an organism can be as short as a few hundred thousand bytes, and that has to be encoded in a way that doesn’t allow for highly clever compression schemes.

This from Wikipedia:

Recent computer hardware advancements include faster processors, more memory, faster video graphics processors, and hardware 3D acceleration. With many of the past’s challenges removed, the focus .... has moved from squeezing as much out of the computer as possible to making stylish, beautiful, well-designed real time artwork

On the other hand, Baez's friend Bruce Smith produced this video (sans hardware infrastructure) in 4KB (that's a rounding error on a rounding error in most programs today). So, don't say it can't be done; don't accept bloat; be lean!

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Keep calm and carry on

Mike Clayton has a suscint post built around this WW II poster--which, itself, has an interesting history--that summarizes ten ideas for stress management (my editorials added; for Mike's annotation, click on the links):

1. Build in planning time
Of course, if you're not a natural planner, this is toughy, and you may actually be comfortable with the stress of deadlines.

2. Give yourself some contingency
Essentially, #1 operationalized

3. One thing at a time
If you are a natural at multiplexing, go ahead. I, for one, have three books that I am reading in multiplex format

4. A problem shared...
Nothing quite like the sounding board of a creative partner

5. Get up and walk around
What works for me is to change venue. Sometimes I take the laptop to a coffee shop. When working in a corporate setting, sometimes I go to an empty conference room.

6. Tidy up 
Or, don't. It depends on if 'tidy' adds comfort or stress

7. Smart snacking
This one never works for me, so I don't keep any snacks around, except fruit

8. Have a rant...
... but choose your timing carefully
Actually, this one's not for me, either in person or by email (horrors!). Better left unsaid that which you can't afford to live with

9. Stress is a part of success
Yes, it is. Everyone needs stress to function; it's a matter of degree

10. Focus on your achievements
Yes, this is a good one from time to time.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Think like a beginner

"Think like a beginner!"

That's the big take away from an interview with Salesforce.com CEO Mark Benioff. And, what exactly, does that mean, and what does it mean for project management?

Benioff was pontificating on why some established organizations can't get on the page of destructive innovation, and why they can't seem to get past a one-trick success. His take: they don't think like beginners... they don't think like they did when everything was a blank story board and they had no legacy to preseve and no install base to keep relevant.

Example: According to Benioff, failure to think like a beginner explains, in part, why Microsoft missed the mobile market. According to Benioff, who was a Apple guy when Jobs was there doing the Mac, the genius of Jobs was his ability to constantly think like he was starting over. Thus, Apple came in and destructively innovated the mobile market, unlike MS, in spite of both having a large legacy install base of personal computers and PC applications.

And, this is not first time Apple was willing to throw away the legacy, in spite of customer angst. Apple was the first to throw away the "A" drive at time when people had hundreds, if not thousands of records on 1Mb floppies. Instant obsolescence of the installed base. Apple's reply to customers: "get over it!"

So, what about projects? In most cases the project manager is not the product manager, not even the product owner. (Owner vs manager: I'm making a distinction between an inward looking manager and a outward looking manager, the latter having the larger portfolio (scope)). The project manager pretty much builds what the product owner wants, especially if the agile mindset is followed.  There isn't any doubt that Apple project manager's developed what Jobs wanted.

So, is there a place for the project manager to indulge in "destructive innovation"? Yes and no is the indefinite answer. To restate the obvious: anyone can have a good idea. But of course, not everyone takes--or can take--responsibility for consequences. That's where project management comes in: the PM is accustomed to accountability. If there's a good idea--requiring everyone to think like a beginner--there's no beginning if someone does not step up to the opportunity. Someone has to be the risk manager--and guess what, there's no doubt who that is: PM every time.

Bookmark this on Delicious

December 7, 1941

December 7, 1941: A day that will live in infamy!

To see how this ends, I suggest reading Max Hastings' brilliant history of the Pacific war  for 1944-1945, entitled appropriately, "Retribution"

Bookmark this on Delicious

Kahneman and Tversky

Daniel Kahneman and Amos Tversky have written notable papers about the biases that infect and affect project estimates, the business case, and all communications with executives and stakeholders. These papers are simply nothing other than "must reading" for every project manager.

I've posted about these guys and their ideas before.

Kahneman won the Nobel prize for his contributions, and if Tversky had not died in 1996, four years before the Nobel award, he would have been in Stockholm with his colleague for a joint award.

Now, Kahneman is out with a new book, some 500 pages--perhaps best read (or sampled) on an e-reader--to explain another idea. This idea is about how we think and what drives decision-making. Entitled "Thinking, Fast and Slow ", it posits a System 1 process and a System 2 process. System 1 and 2 are not new inventions by Kahneman, but his tour-de-force through the concepts is a work worth reading.

The idea is simple on the outside: System 1 is nearly unconscious thinking--effectively nearly instant reactive thinking. Everything from survival to instant analysis, like finding an open receiver downfield. System 2 is conscious analysis, slower than System 1, though not necessarily slow. These two ideas inform the title of this tome: Thinking, fast and slow.

Kahnenman writes: "Much of the discussion in this book is about biases of intuition.... my aim ... is to improve the ability to identify and understand errors of judgmenet and choice ....by providing a richer and more precise language to describe them."

And, here's one we can all identify with: "Unfortunately, professionals' intuition does not arise from true experience", indeed, executive "... judgments and decisions are [often] guided by feelings of liking and disliking, with little deliberation or reasoning". For the quantitative manager, decision making driven by such intuitive thinking is the height of frustration!

Summary: it's a tome to be sure, but it's a good read, and worthy of scanning and sampling--highlighting and bookmarking in an e-reader (there are many free ones for laptops and tablets).



Now,

Bookmark this on Delicious

To think first

“It took a year of thinking before we built any prototypes,”

Serge Montambault,

Mechanical engineer with Hydro Québec’s research institute

And, to top it all off, his project to build robots to inspect high power transmission lines is a business success.

It's remarkable what thinking will do. And of course, take note that from thinking, the next step was prototypes, not full scale development.

Remember the spiral method? It's a prototype-first idea from the last century, inspired by Dr. Barry Boehm of then-TRW. His idea: you can't be sure of which direction to step off when faced with technology feasibility issues, so take the time to experiment to find the right direction.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Why plan

It's agile! Why plan?

Do we really need to answer this?

Yes, we do!

If there are no plans, any outcome is acceptable; if there are no plans, there is nothing to estimate; without estimates, there is no reason to measure.

Without measurements, there will be no benchmarks, no improvement, and no answer to the questions of where are we? and what are we doing?

In fact, without a plan, anywhere and anything will do.

"Project management the agile way: making it work in the enterprise"

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

The server ate my homework

The server ate my homework! In a recent article, I learned that some schools are taking big steps and making wholesale changes to introduce technology in the classroom. Here I find out that students do work on laptops--provided by the school--and in real time teachers track progress and problems on a linked iPad. Now that's interesting integration!

On the other hand, that's a lot of change management, and a lot of change management for what is commonly thought of as a bastion of traditionalism: the K-12 teacher corps.

If successful, whatever is in the water should be bottled and given out to every ERP project. Lord knows that industry could profit by the examples given in the classroom transitions.

Perhaps this was never more true:

If you can't make the trains run on time, do away with the trains

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Value stream mapping

Value stream mapping seems to be a new label on old wine. But nevertheless, the wine ages well. In the old days, we simply called it process mapping.

Value stream mapping derives from the Lean community, where of course the focus is on leaning out non-value add. So, in value stream mapping, each activity, to include the workflow of authorization and other governance, and ancillary activities, like a trouble report or a status report, is evaluated for value-add.

And, of course that begs the question: what is value-add? There is an answer, of course, but it may take a bit of customization to make it work everywhere. Simply put: anything that is ultimately delivered to the customer or makes the customer deliverable a good thing in the customer's eyes.

A lot of governance would not fit this definition directly, but most indirect activities don't. Nevertheless, most practical organizations can't live without them, so there's a certain non-value overhead that goes along with everything.

One thing I do like about value stream mapping is the clarity of the diagramming. Take a look at this diagram:

If you're interested in more, this diagram came from a nice post at LeadingAnswers

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Messy information systems

Do you buy this idea?

... science-based, method-driven approaches can be misleading. Contrary to their promise, they are deceivingly abstract and removed from practice. Everyone can experience this when he or she moves from the models to the implementation phase. The words of caution and pleas for ‘change management’ interventions that usually accompany the sophisticated methods and polished models keep reminding us of such an implementation gap. However, they offer no valid clue on how to overcome it…

Does this mean you have to see it to believe it, or does it just validate the ideas of progressive elaboration (defined in the PMBOK as continuous improvement and refinement) or emergence (unpredicted--though perhaps predictable--interactions of system elements that become known)--or neither?

No matter how you go on this, you might like the book review of "The Labyrinths of Information: Challenging the Wisdom of Systems" by Claudio Ciborra as reviewed by EightToLate

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

The project sentence

Richard Feynman is a renown theoretical physicist (deceased 1988).

He once said that if he had to summarize modern science in one sentence he would choose: "The world is made of atoms".

Brian Greene, also a theoretical physicist, has written of Feynman's choice: "When we recognize that so much of our understanding of the universe relies on the properties and interactions of atoms......we can well appreciate Feynman's choice for encapsulating our scientific legacy."

And, there are other sentences. Many have said: "The business of business is business", meaning customers are swell, but shareholder value is better!

So, what about a project sentence? It would be great it would unify the three great values of project management:

1. Customer value (value as experienced by the customer)
2. Business value (value returned to the business as a consequence of project activity), and
3. Earned value (a measure of the effective utilization of the business resources committed to the project)

And, it would be neutral on plan driven vs outcome driven (agile)

So, how about this?

The business of projects is to effectively invest business assets to return to stakeholders value from the affirmative vote of customers

Brian Greene: "The Fabric of the Cosmos"
Photo

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

About change

Change is the price of survival

Gary Player

Professional golfer

Bookmark this on Delicious

PMBOK Software projects practice standard

LeadingAnswers has a nice summary of the motivations behind the practice standard for software projects now being put together by PMI. It's barely an outline now, but it will soon be joining the other practice standards that are either unique to an industry or to a domain, like construction and US Defense Department.

Here's a look at some of the issues to be addressed in the words of LeadingAnswers:

• Specification problems – software projects are hard to define because they are intangible and hard to reference.
• Evaluation Problems – We really need to see and use software to say if it is suitable for us, reading a spec is a poor method for validating functionality. IWKIWISI – I Will Know It When I See It applies.
• Knowledge Worker domain – we are using subject matter experts to collaborate and share information rather than industrial works to repeat a defined process.
• Speed of business change – system requirements change frequently as businesses evolve and change. Change rates are higher than in many other project domains.
• Building with bits and not atoms – we are manipulating information and models not concrete and steel so our processes and controls need to be different.
• Non-Linear progression – progress is often non-linear. Some things go quickly some things take a long time. Approaches that assume a linear progression to completion are more problematic to apply on software projects.
• Uncertainty – We have more technology uncertainty and requirements uncertainty than many other industries and so need more tools to checkpoint and adjust if necessary.
• Extreme modifibility – unlike physical construction where is difficult to move a bridge upstream when it is 75% complete, there are some changes that can be done late in software projects that have few parallels in other domains.

Here's my take: Software projects are "idea" projects. They are almost without boundary, both internally and externally. Not entirely of course: where the software meets the hardware, there is a boundary to be sure, especially if you are developing for an embedded processor, like a guidance computer in the tip of a weapon.

About ideas: ideas have no natural limitations: we all know that; it's unreasonable to imagine all ideas are ever known; ideas are volatile; ideas emerge and evolve with experience; ultimately ideas drive vision; and vision is the source of business value.

So, software projects are always going inherit the basic properties of ideas. As such, we need methods and management paradigms like agile to deal with ideas.

At the same time, projects more often than not spend other people's money (OPM). When you are responsible--and, gasp!, accountable--for OPM, your whole perspective changes. Order and predictability become very important.

A marriage of enterprise management skills and agile management skills perhaps is the answer. Anyway, that's what I been saying for a few years now.

Bookmark this on Delicious

Gladwell on intuition

“A tremendous amount of expertise lies in the unconscious mind ….. Anyone juggling many different variables, dealing with incredibly new and complex issues, … has to, at some point, rely on this body of submerged knowledge to make sense of their tasks”

Malcolm Gladwell

Complexity

Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them

Laurence J. Peter

I'll think I'll just let this one stand, but if you want to read more, browse through this explanation of the "wicked problem".

Bookmark this on Delicious

Option management

I often hesitate to import risk management ideas from the financial sector into the project management domain--afterall, the risk management results in the financial sector have not been swell of late, and projects are not casino's--but the idea of "options" does port well to projects.

And an option is:
An option is a "right" that you buy for a small fee; then, you have the option to exercise your right at a later time. You can buy the right to buy a security at a specific price not later than a specific date, or you can buy the right to sell a security at a specific time at a specific price.

If you don't exercise the right you paid for, you lose the money you paid for the option. Obviously, you would only exercise your option if the transaction is profitable for you.

Option risk management features:
There are a couple of interesting features embedded in the option transaction that are attractive from a risk management perspective:

• Time displacement (the distance between present and future) is usually a risk nemesis, but in options, time is on your side.  Lemons become lemonade, as it where.  In order for an option to become profitable, some time must pass during which the security changes value, hopefully in your favor. (Most securities trading works this way)
• Downside risk is protected.  The most you can lose (if you act rationally) is your fee for the right to the option, thus protecting you from the actual loss of the value of the security
• Upside opportunity is amplified. Options leverage the value of the fee you paid.  For your small fee, you may be able to participate in a very large gain, which on a percentage basis, is far greater than just trading the security.

Options in projects (and portfolios)
Let's say you anticipate a make/buy juncture in the project 2-4 months out (we never use single point estimates here at Musings).  Two chains of project activities radiate from this decision event: one chain supports a 'buy' decision (essentially, outsource to a supplier) and one chain supports a 'make' decision (do all the work in-house). 

An option scenario is that you do something now to protect your right to go either way at the decision event.  You make a small investment now in order that 'no options are off the table'.

Done right, you make a friend of time: time can be used to set up the conditions for a decision that might not otherwise be available.  By protecting both eventualities, you protect agains the downside of poor alternative, or an alternative foregone because of no preparation.  And, of course, your small investment may be highly leveraged: a great outcome made more likely by a small fee for preparation.

Investment possibilities
So, what are some things you might do? A few prototypes to test your in house capability; some training of staff in skills that might be needed; some due-diligence and benchmarking on the supply chain; and some research into the various vehicles for outsourcing, like incentive contracts, etc.

If you are portfolio manager, then options in the form of independent R&D (IR&D, or IRaD) is a good way to invest a small amount now in order to have project options in the future. And, of course, investing in your customer (things you know your customer wants to do is perhaps the best use of internal investment)

Oh, and how big is "small" in the investment we are talking about?  No right answer of course, but a few percent of the value of the opportunity you are protecting is not a bad figure.

To learn more
If you want to see some numerical examples worked through, go to the Khan Academy and search for the short videos on options.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Hold a meeting

How many "how to hold a meeting" guides are there? More than enough!

So it caught my eye that no less an eminence than Donald Rumsfeld is giving his ideas on how to hold a meeting. He's on slide 8 of Bloomberg Businessweek's How To issue for September 2011.

He has four points, and three of the four are mundane: start on time/end on time, speak without jargon, and be inclusive (more on this later).

But he has one point that seems less obvious: no matter the subject, start with assumptions.

Why? Well, according to Don (can I address him as Don?) assumptions let's everyone know if they are likely to be in agreement with the topic. If so, it shortcuts the discussion of the unncessary so that the presenter can move directly to the punch line. Perhaps so. I'll be giving it a try.

On the other thing, being inclusive: not in Rumsfeld's written missive, but attributed to him by those in the know (as heard on "Morning Joe" on MSNBC), Rumy would often 'dis-invite' those that he knew did not speak up, did not offer critical thinking, and thus were unlikely to add value. So, inclusive yes; but only if likely to add something to the discussion. At the risk of group-think, which is not necessarily implied, I like this one also.

So, two good points!

Photo

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Project balance sheet

If you follow this blog you've read several references to the project balance sheet. So, is this about accounting? Yes, and no: Yes, it's about a double entry tool to keep track of "mine" and "yours", but no, it's not the accountant's tool used in your father's accounting office.

Take a look at this figure:

What have we got here?

First, 'mine' and 'yours'.

On the left side of the balance sheet is the sponsor's investment in the project. Investment need not be all monetized. It's the 'your's side of the balance sheet, somewhat akin to the right side of the financial balance sheet (money owed to creditors and money invested by owners). 'Yours' simply means it's resources owned by others and provided to the project.

On the right side is the 'mine' side of the project balance sheet, akin to the left side of the financial accounting sheet (assets owned by the business). The right side is the project side, and the right side shows the estimates and evaluations of the project manager.

And, take note: the left side, the sponsor's side, is the fact-free zone: it's a top down allocation of resources to the vision. It is the ultimate utility expression of the sponsors: what's valuable, and how valuable, even if not entirely objective. And on the right side, it's all about facts (benchmarks) and estimates (benchmarks applied to project circumstances). It's bottom up.

Of course, there's the inevitable gap where utility collides with facts and fact-based estimates. The gap is the risk between expectations and capacity-capability. And how large is the gap (risk): only as large as needed to create a balance--that is, a deal with the devil--so that the project can go forward.

 In other words, the gap (risk), shown on the project side, is only as large as it needs to be to close the gap. Usually, it's a matter of negotiation, but once the PMB is set, the risk is the PM's responsibility to manage.

In other words, the PM is the ultimate risk manager.

In a real world example, I had this situation:

• We bid a job competitively in a firm fixed price environment. 
• We offered a price that was equal to our cost; in other words, no fee (profit).  We just wanted to keep the lights on and keep barriers to competition with our customer as high as possible. 
• We won! 
• And, in  the next moment, my general manager said: "Your bonus depends on making 4% net margin".  I had my gap!  (oh yes, I made the margin and the customer was satisfied)

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

The human element

The one element that can change every element is the human element

Dow Chemical tag line

People are our most valuable resource--correct?  Well, that's always the line, but is it the reality? Lest we all forget,  the 'facts' are that on the financial balance sheet, the one executives look at, people are a liability (accrued benefits and compensation), and on the expense statement, they are a cost. 

But, fortunately on the project balance sheet, they're assets.   Recall: the project balance sheet and the financial balance sheet are not the same animal.  The former is a view of the top down/bottom up balance in the project, and the latter is a view of the distribution of monetary ownership between the business and it's benefactors.

Bottom line: there's a natural tension between business and projects, and the human resource is a part of that tension.

Bookmark this on Delicious

 Bookmark this on Delicious  

Risk waterfall, or not

Waterfall is a four letter word in the project management space.

Everyone will tell you they understand the hazards and seek a more effective paradigm. Actually, the synonym is sequential process (sounds better, and more sophisticated) and the better idea, practiced by most, is sequences with iteration and feedback.

Most understand the idea of feedback as a control device (for those that want to brush up, a good read is Donella Meadows' book "Thinking in Systems"). So, when you combine a control device with the opportunity to do over or correct, you've got a sequence under control, and a sequence that is responsive to outcome demand.

Nice.

Now, the agilists call an iterative sequence under control just common sense, or complex adaptive (perhaps so, in some cases) or emergent (closer to what actually happens). But, usually the discussion on this topic is all about the vision, the requirements backlog, and the intended product or process outcome. The risk register--indeed, the whole RM process--is often ignored, or just not in the discussion.

Where does the classic RM sequence fit in? Recall the sequence: set the context; identify risks; qualitatively and quantitatively assess the risks; plan responses; do, monitor, and control the response and its impact.

Now, how does the risk sequence fit into an agile emergent paradigm, or a iterative sequential baseline process?

I posit that the right strategy is to distribute the sequence: the first two steps, set the context and identify the risks, and be done as part of the project business case and the original envisioning.  The latter steps can be allocated to the execution teams.  As such, every time the backlog is reevaluated, so also is the risk register reevaluated (thus, iteration to the project charter) and the assessment, response planning, and monitor/control are incorporated into the team work of each time box or other scope segment.

So, in effect, the sequential process, with feedback, is made iterative by time box or scope segment as matter of methodology design and management policy.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.