The plan is to persevere

"... all things are always on the move simultaneously ... One has to do the best one can, but he is an unwise man who thinks there is any certain way .... The only plan is to persevere"

Winston Churchill as quoted by Max Hastings in "Retribution"

With this bit of wisdom tucked away, one can only marvel at the multi-tasking capability of the human mind,  the tolerance most have for distraction, and the dynamic range we deal with from the trivial to the calamitous, with normal in between! Could Watson ever do as well?

Bookmark this on Delicious

Do the math!

A funny thing happened on the way to advanced project management. Too many want the mantle but too few want to do the math. In fact, the PMBOK 4th edition has less math in it than the 3rd edition.

Project managers are most often judged on their metric performance--cost and schedule, etc--but few want to invest in the math skills to drive the metrics better.

For those wanting to catch up a bit, I strongly recommend the 15 minute videos at the online Khan Academy. You can start back in the 5th grade and work yourself through a graduate education in math and statistics. And, it's free. And, it's in bite size chucks. Here's a sample:

Bookmark this on Delicious

It takes a Theme

Definition: A theme is the central idea or ideas explored .....

While you might start with an issue or theme in mind, themes will also develop or emerge as you write. It may not be until the editing stage that you even begin to recognize your themes. Having recognized them, your themes will help you determine what to cut .... and what to highlight.

Quoted from About.com

So, as between message, messenger, and presentation--the three pillars of communication--themes are the message. And, they show up everywhere:

• Portfolios: Ask this: what's the message of the portfolio that binds the constituent programs, projects, and initiatives together?

In my PMO days, I had one portfolio that was exclusively CRM (customer relationship management); the message we wrote conveyed our idea of customer intimacy. (Remember Michael Treacy's and Fred Wiersema's 1993 paper in the Harvard Business Review: "Customer Intimacy and other Value Disciplines"? Intimacy, operational excellence, or product excellence are the big three)

• Programs: like a portfolio, the "big idea".

• Projects: the theme should come right out of the charter, the raison d'être as it were: why are we doing this project, or what's it to accomplish.

The agile guys have picked up the "theme" thing. In fact, agilists say that portfolios have "investment themes", the driving message for why invest in this or that portfolio.  I like that one. And, then themes tie to epics--the top level narrative that explains what's going on. Leffingwell writes:

Epics are development initiatives that are intended to deliver the value of an investment theme and are identified, prioritized, estimated, and maintained in the portfolio backlog.

Agile Software Requirements

And, let's not forget marketing and sales; they've been around for centuries. In modern days for project managers it's proposals, the response to an RFP. Right up there in the executive summary ought to be the win theme--why me (or us)? If you've not tried to write such a message, give it a try sometime. You might find the message harder than it looks to get succint, effective, and memorable!

    Bookmark this on Delicious

Experience from synergy

Mike Cohn has a nice posting on something he calls "communities of practice" but which I think of as experience from the synergy of multiple players. Regardless of how you label it, I think his diagram says a lot:

Looking carefully at the diagram, notice both cross team and intra-team (vertical) participation in the "communities" (horizontal). Mike is Scrum-centric, so his diagram has a Scum master community. If I'd done the drawing, I would've been less prochial since there are many competing methodologies, other than Scrum, that provide quite good agile experiences.

And, by the way, this is not an agile idea per se. I've been doing things like this in the defense and aerospace business for years (old wine, new bottle?). However, Mike's presentation is very effective. (Remember: communications = message + messenger + presentation)

And, of course, the diagram is only a hint at what you can do. It's probably best to extend this to a program or portfolio. The PMO often instigates and sponsors such collaboration.

Many groups call such a matrix "birds of a feather". I have attended many "birds of a feather" collaborations at conferences and such. But Mike is saying: make it a regular and sustained practice, not just an occasional get together.

Good advice!

Bookmark this on Delicious

Tell me again, what's risk management?

When I teach risk management, I always get these three issues:

The risk register, if it's done at all, is a dead end. You do it, probably up front, and rarely revisit it. And, you don't budget (or, are not allowed to budget) for the response plans, and like a dangling participle, the RR never connects to the real project (aka, baseline).

But, hey check a square: the RR is done! (And, so is risk management. Whew! that was hard stuff)

Second issue: Evaluating the quality of an estimate, or evaluating the quality of incomplete information--as from a sample--is said to be "not risk management". It's estimating or it's decision-making or it's sampling or it's quality management, but it's not risk management.

And third: without a formal process--like the six steps in the risk management knowledge area of the PMBOK as an example--there's no risk management going on, or there's no risk management that can go on.

Well, the first issue is troublesome, but not fatal. As many have said: "It's not the plan, it's the planning that has value". If''ve you got no funding, and an insensitive sponsor, then your risk response plan is "accept the risk". But, having done the planning, you'll be that far ahead if the risk event actually occurs. Not great, but usually not fatal.

The second is just misunderstandings. There're no facts about the future; only estimates in the present of what the future could be. There's uncertainty in every estimate, and thus by definition, there's risk. Risk management ideas apply, even if you don't do a risk register for every estimate. And, by the way, nobody does except for those estimates that have material strategic impact to the project. Otherwise, you fall back to reasonably accepted practices, like 3 point estimates and Monte Carlo simulations. That's risk management, even if it's estimating also.

The third is another form of misunderstanding. Everyone thinks about and manages risk every day, from driving to work to putting hot coffee in your lap. It doesn't take a formal process, but the mind, either working in System 1 or System 2, rapidly steps through identification, prioritization, evaluation, and response. You may not be conscious of the systematic way you process risks.

Of course, what about safety engineering and design? Doesn't that incorporate risk management in projects? And, don't leave out the "ilities". Mean time between failures (MTBF), mean time to repair (MTTR), and other "ilities" are all based on statistical uncertainty and statistical models. Where would projects be without the Poisson or Exponential distributions?

And, what about post-project business risks? These reflect back into the project as effects on performance, functionality, feature, and aesthetic appeal. Shouldn't these risks be "risk management" to the project manager?

And, on an even larger scale, every alert project decider considers the consequences, to include the affordability (or not) of consequences, in everything decided. That's risk management also. It's just not written down.

So, everyone's a risk manager, all day, every day!

Bookmark this on Delicious

Agile oscillators

When I first got out of engineering school, one of my first projects was to build an oscillator. An oscillator is a device--should I call it an object?--with "just enough" reinforcing feedback of output back to input, with the feedback arrival timed just so, such that there is a constantly varying cyclic output, swinging first one way and then the other.

The nature of the varying cyclic output can be quite jarring, or it can be nuanced and smoothed out:

Now, along comes Agile, and my thoughts go back to the oscillator. And, I'm not the only one. Jim Highsmith has been thinking about the same thing. The architecture (stucture and behaviors) of all agile methods includes feedback, mostly from customers/users, but also from sponsors/stakeholders. The mandate for agile teams is to respond, and be responsive, to feedback. That is, a sample of output--in the form of user experience--becomes a part of the input to the deliberations of the agile team.

Now, if the feedback is phased (timed) one way, it will stablize the iteration. Change the timing a bit and it will destablize the iteration and cause oscillations. In effect, the team builds one thing, only to find out--in the wrong timing--that the customer has changed their mind; the team responds to the change. But, meanwhile, the customer is experiencing the wrong (earlier) thing and seeks correction. Ooops! the team is driven back, or a different way.

If the timing is never corrected, the iteration becomes oscillatory and really nothing gets done.

Time for the project manager to step in and call a halt and dampen the oscillations. Everyone needs to take an Iteration 0 break to do a little reflection and get the timing reset. Maybe a spike needs to be inserted to allow for some non-deliverable prototyping or modeling.

In any event, oscillations can not be allowed for more than a cycle, perhaps two. If not naturally damped out, the PM must take action!

Bookmark this on Delicious

Square root of 2, and more!

I started to tag this posting "trivia" but thought better of it. But I was interested to learn from John Baez, a mathematician of some renown, that the Babylonians had pretty much worked out the square root of 2, an irrational number not the ratio of anything, and they did it using a number system with base 60.

Here's the proof, according to mathematician Baez. A tablet, written by a beginner because of the large lettering, has sides of length 1/2 (30 in base 60) and writing that shows the calculation of the diagonal to an excellent approximation of Sqrt(2)*1/2, or 1/Sqrt(2).

Baez explains:

Well, actually, there's no evidence that the Babylonians (now, Iraqis) ever knew about irrational numbers. They expressed everything in fractions and used approximations.

And that by the way is the lesson for project managers: we live in the one-sigma world where a decent approximation is "good enough". A lot of really good project management gets along fine on approximations. We can leave to Dr Baez to give us the theoretical underpinnings!

Bookmark this on Delicious

What are you doing?

If you can’t describe what you are doing as a process, you don’t know what you’re doing.

W. Edwards Deming

Bookmark this on Delicious

Government technology opportunity

TechAmerica has issued a very readable report entitled Government Technology Opportunity in the 21st Century. There are four top level recommendations:

1. Develop a Professional Program Management Capability (you might ask: isn't this a long time coming? Hasn't the US federal government been in this business since WW II?)
2. Promote Agile/Incremental Development (Now of course this is a genuine newbie)
3. Strengthen Risk Management (again, a bit late, but welcome anyway)
4. Enhance Internal and External Engagement (needed for agile, but needed in any event)

On the first point, this telling quote from someone who contributed to the report:

“Strong program managers have overcome poor requirements, aggressive milestones, limited resources and constrained processes to deliver mission capability, while processes have not been able to compensate for a poor program manager even with clear requirements and sufficient resources.”

On the second point, we are told this:

The benefits of agile/incremental development can be seen in the results of a survey of commercial IT developers published in the June 2008 issue of Dr. Dobb’s Journal and cited by Scott Ambler, Chief Methodologist for Agile and Lean at IBM, in discussing the effectiveness of the methodology.

Survey respondents compared agile to other methodologies and rated it as follows:

 Productivity—82% rated it somewhat or much higher
 Business Stakeholder Satisfaction—78% somewhat or much higher
 Quality—77% somewhat or much higher
 System Development Cost—72% somewhat or much lower

To implement agile, the report goes on to cite a few regulatory and cultural hurdles to overcome. Glen Alleman puts it this way:

... self directed teams sitting in the same room with their customer, letting the requirements emerge as the money is being spent, probably isn't going to pass the smell test of Congressional oversight of spending the public's money

Nevertheless, if the recommendations in this report are acted upon, the federal IT business will be the better for it.

Bookmark this on Delicious

Agile PMO

Over at Eight to Late, Mike Griffiths has a slide presentation on the agile PMO. He tells how the PMO can go from Present Many Obstacles to Provide Many Opportunities.

It's a nice play on the words, but there are some instructive ideas in the slide deck (available for download), if you can abide the agile-is-only-way arguments.

First, Griffiths builds the presentation around 9 bullets that are the things that PMO's are supposed to do:

Then he fills in details--from his point of view--about how traditionally managed PMO's need to change--a new game theory in his mind--to be compatible and useful to agile projects.

Of course, a balanced point of view is not Mike's forte. This is a red meat "preaching to the choir" presentation given to an agile conference of agilists.

For example, under bad old way, we read:
Monitor and control project performance – track progress against
inappropriate measures such as getting requirements fully documented and
signed off

Under agile is the silver bullet, we read:
Monitor and control project performance – track velocity, track team and
sponsor satisfaction ratings, look for dangerous velocity trends, check
backlog size, monitor iteration and release plans

Now, I count myself among practical agilists, as explained in my book, but I also know that literally billions of lines of code written the bad old way are up and working fine, so whereas I agree this generation has a good idea in agile, it's not the only game in town.

For another perspective on portfolios and agile, take a look at this:

Portfolio management and agile: a look at risk and value

View more presentations from John Goodpasture

Bookmark this on Delicious

Disorder

Brian Greene is a superstring theoretical physicist and mathematician with a flair for communications. This fall he has been hosting a public broadcasting series on the fabric of the cosmos, based in part on his book, brilliantly written, of the same title.

Of course, the fabric of the cosmos is not about project management, but it is about complexity, and that's something we all endure in projects and in life.

One principle Dr Greene writes about struck me as spot on: the more complex a system is, the more disorderly it is. In fact, the natural tendency of complex systems, if not otherwise constrained, is to seek disorder.

On one level it's intuitively obvious: the number of communication paths between N devices approaches N-squared when N is large. Every communication path is a potential pathway to trouble.

So, when I read the literature on Lean thinking, the ideas of small batches, limited backlog, and minimialist tasks is all the more striking. Maybe the lean guys are onto something!

And the agilists and Kanban'ers have it going also: keep everything as small and simple as possible--like one sentence story cards and simple use case models--just like our friend Einstein counseled ("Make everything as simple as possible but not simpler"). Of course the simplest possible can still be complex, but at least we made the effort.

And, one more thing: that principle we started with--it was developed in the 19th century as the 2nd Law of Thermodynamics. Who knew!?

Bookmark this on Delicious

Adopting agile

To succeed with agile, management’s need for results must be greater than their need for control. —Israel Gat, formerly of BMC Software

This statement is so profound, I think I'll just let it stand on its own.

Source: Originally quoted by Dean Leffingwell in "Agile Software Requirements", Chapter 22.

Bookmark this on Delicious

 

Predicting the future

The best way to predict the future is to invent it

Alan Kay, computer scientist

One might have thought this would have been a Steve Jobs quote, but no--there are other innovators.

Of course, the point is that opportunities are only as valuable as we make them by engaging and applying ingenuity and effort. And, if the future is not as bright as needed, then envision what's needed and go "all in"

Bookmark this on Delicious

IT risk management spending

In a recent posting, we are told that IT spending on various business services for risk management in business processes will out pace the traditional IT spending on financial applications.  Everything from asset management to information security. 

And, in another article, we are told that personal data privacy is only going to grow in importance and compliance demands. That's a good thing!

Wow! That's quite a development. Perhaps risk management has arrived at last.

And to projects and project managers, it all rolls downhill. We should expect to be evaluating, developing, and validating all manner of risk management applications and services.

And here's a thought: We may find ourselves using risk management to evaluate risk management!

Bookmark this on Delicious

NICE Cyber

The National Initiative for Cyber Education (NICE) is hard at work.  From their website, we learn that: "Today, there is little consistency in how cybersecurity work is defined and described throughout the nation. The lack of a common language to discuss and understand the work requirements of cybersecurity professionals hinders our nation's ability to:
-Baseline capabilities,
-Identify skill gaps,
-Develop cybersecurity talent in the workforce, and
-Prepare the pipeline of future talent."

Thus, a workforce framework has been developed by NICE, a unit of the National Institute of Standards and Technology (NIST).

The seven NICE categories are:

1. Securely provision - conceptualizing, designing and building secure IT systems;

• Information assurance compliance
• Software engineering
• Enterprise architecture
• Technology Demonstration
• Systems requirements planning
• Test and evaluation
• Systems development.

2. Operate and maintain - the support, administration and maintenance necessary to ensure effective and efficient IT system performance and security;

• Data administration
• Information system security management
• Knowledge management
• Customer service and technical support
• Network services
• System administration
• Systems security analysis.

3. Protect and defend - the identification, analysis, and mitigation of threats to IT systems and networks;

• Computer network defense
• Incident response
• Computer network defense infrastructure support
• Security program management
• Vulnerability assessment and management.

4. Investigate - investigation of cyber events or crimes, which occur within IT systems or networks, as well as the processing and use of digital evidence;

• Investigation
• Digital forensics.

5. Operate and collect - the highly specialized collection of cybersecurity information that may be used to develop intelligence;

• Collection operations
• Cyber operations planning
• Cyber operations.

6. Analyze - review and evaluation of incoming cybersecurity information to determine its usefulness for intelligence;

• Cyber threat analysis
• Exploitation analysis
• All source intelligence
• Targets.

7. Support - specialty areas that provide critical support so that others may effectively conduct their cybersecurity work;

• Legal advice and advocacy
• Strategic planning and policy development
• Education and training.

 

Bookmark this on Delicious

Happy New Year!

Photo