Tuesday, April 30, 2013
Changing the RMP exam
If you're thinking about taking the RMP exam for risk management credentials from PMI, you should be aware that the test content will change in August, 2013.
PMI has recently completed a RDS (Role Delination Study) for the RMP. A FAQ on this RDS is useful reading if you are headed for the test this year.
PMI has updated the outline of the RMP test content, adding one domain (now five) for testing and expanding the tasks within domains to 31.
Take note: the five domains vis a vis the RMP exam are not mapped to the six process steps of the risk management knowledge area in Chapter 11 of the 5th Edition to the PMBOK Guide. This is something you would have to do for yourself if you want to get the relationships here.
And, by the way, the 5th Edition is the one to study for the test. (Don't forget the PMI Practice Standard for Risk Management, a new version of which has not been published)
Check out these books I've written in the library at Square Peg Consulting
Labels:
Risk Management
Sunday, April 28, 2013
Book review for Maximizing Project Value
Shim Marom, who blogs at quantmleap.com, recently reviewed my latest book "Maximizing Project Value".
And, Glen Alleman has a "first look" review as well.
Every author is grateful for a critical review, and I'm no different. You'll find not only a review of my book, but thoughtful reviews of a number of books at quantmleap.com.
Of course, in keeping with the state of the art in the book business, you can get this book in paper, Kindle, and google ebook format.
Check out these books I've written in the library at Square Peg Consulting
Labels:
books,
Project Value
Friday, April 26, 2013
NIST Cyber framework
Here's an FYI for those with projects in the cyber security domain:
The National Institute of Standards and Technology (NIST) is holding the second of four planned workshops to develop a voluntary framework to reduce cybersecurity risks for critical infrastructurefrom May 29-31, 2013, at Carnegie Mellon University in Pittsburgh, Pa. The hands-on workshop is open to cybersecurity industry experts in all sectors—such as energy, finance, transportation and communications—as well as government and academic stakeholders.
The second workshop on the Cybersecurity Framework will be an opportunity for attendees to identify, refine, and guide the many interrelated considerations, challenges, and efforts needed to develop the Framework. The majority of the workshop will be working sessions where participants will analyze and discuss the initial inputs to the Framework...
Check out these books I've written in the library at Square Peg Consulting
Labels:
cyber
Wednesday, April 24, 2013
Statistics before calculus... really?
Arthur Benjamin -- a math teacher -- posits that calculus, as the pinnacle of the mathematics pyramid is the wrong goal. Rather, it should be statistics. He profers that statistics are the math of daily living: randomness, uncertaintly, risk, reward, even games! It's the math we communicate with more often than calculus (even if many use calculus in daily living and don't know they are doing so)
Here's his argument in less than 3 minutes:
Check out these books I've written in the library at Square Peg Consulting
Labels:
communication,
Statistics
Saturday, April 20, 2013
Systems engineering FAQ
A lot of PMs know they need systems engineering, or think they might, but aren't sure who these folks are or what they do.
Here's my FAQ I used when I was a Director for systems engineering for aerospace and communications firm Harris Corporation.
(And, I tried to make this not to stuffy!)
What is this thing called system engineering?
Here's my FAQ I used when I was a Director for systems engineering for aerospace and communications firm Harris Corporation.
(And, I tried to make this not to stuffy!)
What is this thing called system engineering?
- What is system engineering? Here's the way NASA defines it: "System engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system"
- What do systems engineers (SE) do? Primarily, they have three work areas: system architecture; system feature, function, and performance; and system validation. Included in these three work areas are the system 'ilities', system risk management, major interfaces, and optimization among competing constituents. And, SEs contribute to the major project plans as directed by the PMO.
- Why is system validation one of their responsibilities? First, SEs are independent of the developers -- and independence is a good thing for validation. Second, the SE is charged with maintaining a holistic view of the system; this view should inform system validation procedures. And, third, this puts accountability into the mix: SE is actually in the workstream that makes it work!
- Are there standards and protocols for what SEs do? Yes, like the body of knowledge for project management, there is a generally accepted body of knowledge for SEs. For instance, INCOSE -- the SE counterpart to PMI or APM -- maintains a body of knowledge in their System Engineering Handbook. Among free resources are those in the public domain from the US DoD/SE and NASA. Of course, there's also the ISO standard 26702, among other ISO standards on various disciplines with SE.
- Do SEs have their own workpackage or swim lane? Yes, it's customary to uniquely track cost, schedule, and deliverables of the SE activity
- Who do they report to? Typically, SE reports to the PMO
- What's a good benchmark for cost? Benchmarks depend on the nature of the project. For studies, the SE could be the whole project; for a typical development with a generous system validation activity, SE could be as much as 40% of the cost, but probably not less than 8%.
- Do they have deliverables? Yes, SE is not a level-of-effort; the deliverables depend on the specifics of the project, but for the most part they are plans, specifications, and procedures.
- If SE are the architects, what is architecture? Architecture is that which defines/specifies/describes the overall boundaries of the major components and defines/specifies/describes the interrelationships and behaviors among the components. In some situations, the overall physical appearance and presentation may be part of the architecture
- What are they thinking when a SE talks about a system? I've answered this before, but here's the simple answer: a set of 'things' -- constituents -- interconnected in such a way that they produce their own pattern of behavior over time. The way a system responds to stimulus is a characteristic of the system itself and not necessarily that of any of its constituents
- Should I use SEs to pursue new business? Yes, many have good customer skills and can communicate conceptually to the thinkers in the customer community
- Can I innovate without them? Anyone can be the innovator, but SEs are often cast in the role of coming up with unique and discriminating ways to do things.
- What do I give up if I don't have them? Many projects don't have a SE per se and do just fine. However, on larger projects with complexity and scale, the architecture function is essential. If not an SE, then someone else with that role is needed for the activity
- If my project team does this anyway aren't just redundant? Not really; they bring a mindset, attitude, bias, and skill that is unique to the SE tradecraft.
Labels:
system engineering
Thursday, April 18, 2013
Storytelling with 'big data'
Jeff Bladt and Bob Filbin wrote a concise post at HBR.org about the way they go about applying big data in their business. Their idea:
A Data Scientist's Real Job: StorytellingData is dull; information may be interesting; but stories can be captivating.
It's sales 101: there's the messenger and there's the message. The combination, well made, is what gets the point across.
Authors Bladt and Filbin are talking about how to analyze and present information from a data warehouse or other large repository of data.
They've devised a process in three steps:
- Look only for data that affect your organization's key metrics
This seems obvious on the face of it, but confusion, ambiguity, and incoherence affect all too many data analyses. Look to the business scorecard and/or the project scorecard for the key metrics (a.k.a. Key Performance Indicators, KPI) that really count - Present data so that everyone can grasp the insights
As the authors say: "...never show a regression analysis or a plot from R. In fact, our final presentation had very few numbers - Return to the data with new questions"
This step is continuous improvement -- CI -- applied to storytelling, using feedback from the audience to refine the story and find new chapters
From the project management perspective, these data stories may well come around as requirements. The agilists will handle them as 'user stories' and use cases -- maintaining the conversational character. The traditionalists will structure them into 'shalls' and 'wills'.
Here's my take:
The popular vernacular is 'narrative'. So in the context of data, what's a narrative? Simply said, it's discreet facts -- call them 'data dots' -- sequenced, related, and linked in such a way that a theme emerges and a story -- a narrative -- is evident: a beginning, middle, and ending. In other words, the dots are connected.
Usually, there's a self-evident purpose for constructing a specific story from the data dots, though it's likely that more than one narrative is possible. Just put the dots back in the pot, draw them out again, and connect them differently: same facts, different story!
In any event, the good news for the project is that there is a data source to go back to; the bad news is it's not stationary, subject to updates from business operations.
But data changes...
The project might want to think about capturing a data image and putting it away as a 'static' version. This image capture can be the baseline for requirements. And, even though static, if accessible by an project analysis engine, the project can continue to probe for derived requirements
Check out these books I've written in the library at Square Peg Consulting
Labels:
Requirements
Tuesday, April 16, 2013
Opportunity v Threats (again)
I was stunned by a paragraph in a recent 'briefing' -- "Opportunities are the Same as Threats" -- from the 'Risk Doctor' telling us that threat and opportunity are the same thing, except for a minus ( - ) sign in the impact column.
The proposition was stated thus:
The secret to effective opportunity management is to recognise that an opportunity is the same as a threat, apart from the sign of the impact . Once we see this similarity, the way to address opportunities becomes obvious. We can take the standard risk process which we already use for threats, and apply it to opportunities, with simple modifications to recognise that we are dealing with positive upside risksMy take: Not exactly!
In some situations the six step risk management process described in Chapter 11 might be applicable to opportunities, but most of the time the sponsors, funding, and impact to the baseline or the business scorecard are so remarkably different that a different management paradigm -- SMEs, tasks, workflow, approvals/trade-offs -- is invoked and applied. That said, the opportunity responses in PMPBOK 11.5.2 are still reasonable and applicable, even to a different paradigm than the risk management paradigm.
And, I'm not talking about the simple difference of having a risk register vs an opportunity register. That's just a matter of the database schema -- schemas don't change the facts/estimates/forecasts. You can use one register if you want -- I teach my risk classes using one register for both; the case study for my students has both opportunity and risk.
Allow me this digression: in my risk management classes, I instruct on how to link/map PMBOK 11.5.2 risk responses to opportunity responses by having a common field on which to join. Then, if you want to map between registers, it's a simple matter of joining the registers on the common field. (If you know SQL and relational theory, then you know that if want a many-many relation between separate registers, you'll need a third register that is used as the common place to join)
The larger issue in my mine, unspoken in the Risk Doctor's briefing, is that opportunity and risk are quite different psychologically. One might hope that psychological factors shouldn't drive different managemenet paradigms, but they do because unique factors enter the frame. A simple minus sign ( - ) does not fix this. (And the 'Risk Doctor' knows all of this; he was a co-author of the rather decent book: "Understanding and managing risk attitude" which covers this very material)
If everyone were rational and objective, immune to bias and especially the effects of the non-linearities of utility, we would not have these issues:
- Foremost, Prospect Theory -- an advanced variant of simple expected utility -- tells us that there are profound psychological differences in the way we approach an opportunity vs a threat; that these differences are quite material; and these psychologies lead to quite dramatic decision and planning non-linearities that are quite difficult to calibrate. Fear -- representing risk -- is simply not the flip side of joy -- representing opportunity.
- Second, even though the PMBOK is correct to suggest quite different responses to opportunity as compared to risks, (See Chapter 11, para 11.5) these different responses not just a matter of a minus sign ( - ); it's a matter of how opportunities are handled differently because they are often a change in the baseline or even a change in the business plan.
One simply does not go about changing baselines for opportunity like one responds with planning contingencies to risks from the risk register. There are usually quite different governance paradigms reflecting quite different cultural attitudes about risk vs opportunity.
At this point, some of you may be thinking: Opportunity or change? Are they same, different without a distinction, or really different? I put my ideas in a recent posting. The way I use 'opportunity' brings sales and marketing into the frame; 'change' may not. Thus, there may be quite different paradigms even between opportunity management -- commonly thought of as external to the project -- and change management commonly thought of as internal to the project - And, finally to the anecdotal evidence: in my risk management courses I put this question (risk vs opportunity) to my students. The overwhelming response -- from hundreds of students across the world and industry and government -- is that the two are not handled as just the opposite sign of the other. Indeed, among those that have a formal risk management process, only a few include opportunity in the mix.
And what about this?: 'Taking a risk is just exercising an option for opportunity'. Yes, that's valid also. Just as in finance where options are a common strategy for managing opportunity without obligation, the same can be applied to projects, setting up the possibility (but not the obligation) of exercising an option to take advantage of situation/condition/event if it happens (Berra, Y: if you see a fork in the road, take it!)
The RISK DOCTOR responds: See the posted comments for the RD's response.
Check out these books I've written in the library at Square Peg Consulting
Labels:
Risk Management
Sunday, April 14, 2013
It is Master's Sunday!
Sunday on the back nine at the Master's: the 12th hole at Amen Corner
If you've not been there, put it on your bucket list!
Check out these books I've written in the library at Square Peg Consulting
Labels:
anniversary
Friday, April 12, 2013
Looking for links?
If you're looking for some interesting links, check out these :
Thinking in systems
Thinking in systems -- another list
Books PMs should read and put to use
Agile and Lean
Strictly risk management
Earned value bibliography
Change mangement bibliography
Check out these books I've written in the library at Square Peg Consulting
Labels:
Project Management
Monday, April 8, 2013
Words to plan by..
“Never leave till tomorrow that which you can do today.” - Benjamin Franklin
"Never do today what you can do tomorrow. Something may occur to make you regret your premature action." - Aaron Burr
“Never put off until tomorrow what you can do the day after tomorrow.” - Mark Twain
Check out these books I've written in the library at Square Peg Consulting
Labels:
planning,
Quotations
Saturday, April 6, 2013
Big data begins here!
We learn from this article (free account needed to read the whole thing) that "big data" began in 1854 when the telegraph was integrated into "big railroad" operations. And, a big railroad in 1854 was 500 miles of track with dozens of whistle stops.
The telegraph put a whole lot of near-real time data in the hands of local, regional, and main operations managers for the first time.
There was so much new stuff and so many new connections in the network -- perhaps the first real business operations network -- that something new was needed: The Organization Chart!
Yes, we can now say that the telegraph beget the organization chart! Who knew?
And, this first chart was upside down by today's convention: the little guys were at the top and el supremo was at the bottom -- an inverted pyramid.
And, get this: the organization chart enable delegation with reasonable reporting and metrics -- let's make the trains run on time! And, for the most part they did.
All of this is a heavy load for the domain of dots and dashes!
Check out these books in the library at Square Peg Consulting
Labels:
Project Management
Thursday, April 4, 2013
Vexing change
In a recent discussion about the difficulties of effecting change, I wrote this:
There are these vexing issues about change management generally:
·
The business is not stationary while the change
is ongoing; thus it’s difficult to fix cause and effect. Sometimes only a loose
correlation is possible.
·
Project success—in the sense of change
project—and business success—in the sense of the impact of change on the
business—are often confused; the success (or not) of the former may be
evaluated quite differently than the success (or not) of the latter, all the
more so because the latter takes much longer to evaluate… so which
success/failure are we really addressing?
·
Success/failure is too often measured by evaluating
consumption of input according to plan—as in cash flow—without regard to earned
value of outcomes. (Debate: If the
outcomes are acceptable/successful, but the input consumption is over plan, is
the project successful or not? Some say there must be success of both input and
output; others only evaluate the output)
·
Leaders and managers are largely trained in
process mechanics, less so in the psychology of change, whereas the issues that
dog large scale change are weighted the other way around: more psychological
than process mechanics
·
Leaders and managers fail to grasp that change
and opportunity are nearly synonyms, and that opportunity is the flip side of
risk (See Chapter 11 of PMI PMBOK). Thus, when addressing the opportunity offered by change, they are
also taking on the risk attendant to the opportunity. They fail to grasp that
the body of knowledge re risk management has a lot to offer to the manager
addressing change—like for example game theory and options management.
·
And, finally, when has the business
reached post-change steady-state such that we can say: the change has occurred
and is fully internalized in both culture and operations?
Dilbert is a creation of Scott Adams.
Dilbert is a creation of Scott Adams.
Check out these books in the library at Square Peg Consulting
Tuesday, April 2, 2013
About Past, present, and future
If we open a quarrel between past and present, we shall find that we have lost the future
Winston Churchill, 1940
In 1940, there was a lot "Who shot John?" fingerpointing among politicians trying to fix the blame for the failure of British policy in the 1930's.
Churchill was a target for some; a hero for others.
Churchill's point: in the midst of crises and stress, look forward, not backward
Who among us has not heard that before? But, of course, Sir Winston had a way with words. Certainly, as project managers we come upon and are effected by failed and ineffective policies, either at the project level or higher up in the business. Shrug it off; press on!
Check out these books in the library at Square Peg Consulting
Labels:
Quotations
Subscribe to:
Posts (Atom)