Thursday, December 31, 2015

PMI-ACP exam questions sampler


Leading Answers is one of those sites that more or less specializes in the PMI-ACP exam (there's a lot of other agile stuff there also). They're in the business to sell stuff, but from time to time they offer freebies, as in a recent posting of a sampler of PMI-ACP questions.

If you're interested, here's the kind of stuff you'll find:
1) Where is your team most likely find the first warnings of potential problems?
  1. Retrospectives
  2. Daily stand-ups
  3. Sprint planning
  4. Iteration demos

2) Your upcoming project will be the organization's first use of agile, and the sponsor asks you about tailoring the new methodology. How do you respond?
  1. Customizing the methodology upfront will allow us to streamline the adoption process.
  2. Adapting the new methodology will be a good way for the team to learn about agile practices.
  3. The team should become comfortable with the new methodology before we consider changing it.
  4. We should wait to adjust our practices until we see where the team runs into difficulties applying them.

3) Although your team has completed their last iteration, it hasn't been "approved." What does this mean?
  1. The team still needs to do refactoring and user testing.
  2. In trying out the product increment, the customer thought of another feature to add to the backlog.
  3. In the demo, the customer decided that the team hadn't completed one of the items selected from the backlog for that iteration.
  4. The product increment hasn't passed QA testing.


What more on agile? Available now! The second edition .........


Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, December 28, 2015

Love what you do?


Do you love what you do? Do you like the project and the people there? Good!

Some caution advised: The project does not love you back, though the people on the project may think you are the greatest.

People, we observe, are in constant tension between:
  • 'People are our most important asset', and
  • Liabilities for salary and benefits
And so, which is it: asset or liability?
Before you answer, here's a bit of balance sheet 101:
  • Assets are held by the company and provided to the project office as resources. Obviously the company does not literally hold people per se, except maybe by employment contract, but your commitment to the company is a company asset.  
  • Liabilities are held by others and are loaned to the company to finance assets. In your case, your willingness to wait for your salary and benefit payments is a loan to the company.
  • If you are worth more than they pay you, then that is 'good will'. Good will is an asset in excess of liability, and really is a benefit to the owners/stockholders (who probably don't know you at all if it is a public company)
Now, the project office is on a mission to maximize throughput, which means minimize variable input to just that required to keep constraints optimized [See: Theory of Constraints].

So that means that as soon as you are not an asset, you are a liability. And, the switchover can be instantaneous, or so it seems.

So, back to caution: Your project manager may love you; your project doesn't.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, December 24, 2015

Happy Holidays!




Happy holidays to all!


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, December 22, 2015

Christmas math


You know, I wrote a book on quantitative methods in project management. But somehow I missed covering these equations!




Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Sunday, December 20, 2015

Agile: the Hybrid Operating Principle


What's the hybrid thing?
It's agile coexisting in the same project with a traditional methodology, presumably for the swim lanes that are not software.
Some call hybrid agile as: agile in the waterfall

Are hybrids practical? After all, the traditional is top down planned, most requirements up front, much system testing at the end, etc. Agile is the not-traditional. Can you fashion a hybrid out of these two?

Actually, hybrids are very practical, if one internalizes the "hybrid operating principle"

Hybrid Operating principle
Agile projects are simultaneously strategically stationary and tactically iterative and emergent

I mean by “strategically stationary” that:
  • Whenever and wherever you look, the project has the same strategic intent and predictable business outlook.
  • Strategically stationary is not unique to agile, of course -- traditional methods actually impose stationariness, and business planners do also.  
Strategic intent is what is expressed by the business for the opportunity and vision of the project.
Strategically predictable business outlook
is the outcome that is expected of the project, typically expressed as the mission, but also found on the business scorecard.

I mean by tactically iterative and emergent that:
  • Flexibility is delegated to development teams to solve issues locally;
  • Teams are empowered to respond to the fine details of customer demand while respecting strategic intent in all respects; and
  • Teams are expected to evolve processes in order to be lean, efficient, and frictionless in development.
And this all leads where?
The overlay of strategy with tactics

The upshot of a tactically emergent and iterative risk response is that we may find that actions in the moment are a seeming variance to the strategy—that is, the project plan. But, over time, we may take other actions that converge on the strategy. In effect, we overlay the strategy with tactical expediency at the moment.

What are these actions?

For the Agile work stream, the most common tactical move is adjustment of the iteration backlog, the repository of “stories” or use cases that are the gist of requirements in the Agile methodology. 

Another form of tactical maneuvering is the result of technical or functional debt: those small items which have been left behind on a “punch list” to be completed before the project ends.

And why are these actions taken?

Most commonly, because the customer/user sees a better way to achieve a functionality; sees an unnecessary story that can be dropped; or has been given information about a requirement, heretofore unidentified, that should be added to the backlog.

These debt may cause small changes which may seem to lead off the strategy, but more often they help to converge to the strategic intent.

 



What more on agile? Available now! The second edition .........

Bookmark this on Delicious


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, December 17, 2015

Risk management: time matters


Want to manage risks? Super! It's always a good idea.
Everybody starts with the traditional four steps:
  1. Identify the risk
  2. Prioritize among risks
  3. Evaluate probability and impact
  4. Set up a risk response or mitigation
Actually, there are problems with Step 3
  • It's rare, bordering on "never", that you would know "probability". Why?  Because it's unlikely you would have enough historical quantitative and calibrated data to form an estimate. (Actually, to form an estimate of a distribution from which a estimate of probability can be determined) Thus, you're likely guessing
  • Time matters, and time is not actually explicit in Step 3
And, so what to do?
  •  Substitute the concept of "confidence interval" for a specific probability: less than this, greater than that; or contained within a range of this to that.*
  • Explicitly state the time frame during which the confidence interval applies. After all, the example oft cited is a good one: your confidence it will rain today is a good deal different than your confidence it will rain this week, but the impact may be the same if you are doing project work in the weather.
* Ooops, another problem: a confidence interval is obtained by integrating a probability distribution, but we've just said we don't have the data necessary to form a distribution. So, does a lack of data also invalidate a confidence interval?
  • Strictly speaking, if the actual shape of the confidence "curve" within the interval is important, then yes there is an issue
  • But, if we are, as most of us are, approximating the interval with some end points that are "very likely to contain the real outcome" then the shape of the curve is not so important. Thus: press on!


Available now! The second edition .........
Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, December 14, 2015

Bring on the spreadsheeets


There's a posting I recently read about the "impossibility" of doing project management with spreadsheets. Indeed, no less than six reasons are offered up.

Nonsense!

I've done many successful projects with only a spreadsheet, and many I know have done the same thing.

So, what are these six reasons, and why are they nonsense?
1. Risk of error
Spreadsheets are error-prone; though they are easy to use for statistical calculations, they are not databases.

Well, it's not just statistical calculations, it's calculations for all applications. Try using a database language to do calculations... not the easiest thing.

Errors? Well, of course, there are data entry errors, data overwrite and retention errors, and data retrieval errors. A database is no more attuned to these maladies than a spreadsheet. Indeed, data qualification can be written into the criteria for a spreadsheet cell just like it can for a database record

2. Lack of security
Security is another important point when dealing with spreadsheets. There is no comprehensive solution to the spreadsheet access issue. Not everyone in the team should have access to the files


The author has a point about security. Although there is no comprehensive spreadsheet solution, in fact on most large databases many users have access to both view and create/delete. So, whereas the controls are there, they are largely open to abuse.

3. Nearly no teamwork, collaboration or communication
Planning, forecasting and project management in general involve lots of collaboration. It’s natural for team members to communicate, discuss things, make decisions, plan activities, change goals, alter deadlines etc. Normally two, three and even more departments are involved in the sharing process.

How do you see that collaboration working using a spreadsheet? Is everyone going to update the same document and then email it to the rest?

Work collaboratively in the same document? Yes. Email it around? No! My goodness, those problems were solved years ago.

4. Loss of key information
This comes as a continuation of the point above. When I say, ”sharing,” I mean being able to edit and comment on one document at the same time.

One more unpleasant thing I noticed when I worked predominantly with spreadsheets is that the same information may appear in the same document twice because people are reluctant to delete information “in case it’s useful in the future”. This results in confusion.

You know, when you do a project and notice there are a dozen or more database instances so that there can be experimentation, development, test, and no loss of previous data "in case it's useful in the future" you might wonder if that would be any more burdensome with spreadsheets. The fact is: a database and a spreadsheet are both applications on top of data records. The impulse to not lose anything is the same in either case.

5. Tracking becomes super-difficult
One file is not enough to store everything about complex projects. But multiple files and folders may make it nearly impossible to track the progress of the project.

I understand that project managers must track the status of things but spreadsheets will hardly ever let you do that. 

Yes, industrial strength databases can be effective even with millions of records, whereas spreadsheets are usually constrained to a fraction of that number. So, if your PMO requires millions of records (Lord help you!), you probably should be using a database

6. Poorly managed project history
Spreadsheets just fall apart so much that you cannot figure out how things are interconnected unless you’re working with them day-to-day. Because deleting things may have dramatic results; people colour in unnecessary data, then they use other colours to highlight important information. It’s meaningful in the moment, but a month later no one understands a thing.

Well, you can't have #5 and #6 at the same time. Database schemas can be every bit as daunting as spreadsheet logic. If you are going to have millions of records (#5), you might have hundreds, if not thousands, of tables; and thousands of data points to keep the records unique, so say nothing of the logic of normalization.(#6)

You have to wonder if the guy who wrote this stuff every got beyond a desktop database.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, December 11, 2015

Data splits 3-ways


Andrew Gelman has an interesting observation: Rather than using the median to split data into "above" and "below" the median, putting data into three buckets may often be more effective.

Why? For one thing, the real information may not be how close to the median you are, but are you in the tails? A three way split makes that identification easier (less thinking)

And, continuous data can simply be put in buckets. All those messy data points from continuous variables can just be reduced to +1 , 0, or -1.  How nice!



Of course, to project managers, the idea has been known for a long time: it's kind of like either being +/- one sigma from the mean, or your data points are in the upper or lower tail.

So, Andrew opines: For pure efficiency it’s still best to keep the continuous information, of course, but if you have the a goal of clarity in exposition and you are willing to dichotomize, I say: trichotomize instead.

And, there's this bit of wisdom: "[Andrew] suspects that part of the motivation for dichotomizing is that people like to think deterministically.

For example, instead of giving people a continuous [performance] score and recognizing that different people have different [outcomes] at different times, just set a hard threshold: then you can characterize people deterministically and not have to think so hard about uncertainty and variation.

As Howard Wainer might have said at some point or another: people will work really hard to avoid having to think."


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, December 8, 2015

Layers of redundancy



Over at HerdingCats, there's a posting about the various ways you can think about and employ redundancy in systems design.

As a former Director of System Engineering, I certainly lend my endorsement to what was written, reproduced here as wrought there. [Disclosure: I don't agree with some of the stabs at Agile, but I certainly would add a spear re "no estimates"]

Here's the opening proposition, as posed by HerdingCats:

Redundancy  provides resiliency to the system to withstand disruption within acceptable degradation parameters and to recover within an acceptable time and composite costs and risks


Here are the rules:
  • Absorption rule - is a buffering characteristic that prevents overload of the system. Redundancy can provide this protection.
  • Limit Degradation support rule - provide a lower limit to which the system can degrade before failing. This is he circuit breaker for your home. Also the circuit breaker for the stick exchange.
  • Margin Support Rule - margin is added to the system to protect from disruptions. This can be schedule margin, cost margin, technical performance margin, operational margin. Any kind of margin that allows the system to continue to operate properly inside the range of parameters.
  • Physical Redundancy rule - buy two in case one breaks .... Fault-Tolerant System Reliability in the Presence of Imperfect Diagnostic Coverage, describes how ... triple redundancy was protected through real-time fault detection and dynamic reconfiguration of the hardware components.
  • Functional Redundancy rule - is sometimes called design diversity and avoids the vulnerabilities of Physical Redundancy.
  • Layers of Defense rule - states that for a failure to occur a disturbance has to penetrate a series of layers simulate to layers of Swiss Cheese. The system has holes like the holes in Swiss Cheese, that allow the failure to penetrate to the next level, where they can be handled.



Available now! The second edition .........
Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, December 5, 2015

Admiral Rickover on "responsibility"


Rickover invented project management for the Navy -- or at least the nuclear project Navy. He said a lot of stuff, but this is one that catches your attention:
"Responsibility is a unique concept... You may share it with others, but your portion is not diminished. You may delegate it, but it is still with you... If responsibility is rightfully yours, no evasion, or ignorance or passing the blame can shift the burden to someone else. Unless you can point your finger at the man who is responsible when something goes wrong, then you have never had anyone really responsible"

Read in the library at Square Peg Consulting about these other books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, December 2, 2015

Grand strategy


Every enterprise engages in strategy.
  • It's a matter of routine to some: Driven by the calendar, it's now time to do the "strategic plan".
  • To others, it's another name for how to engage with risk -- a risk might be a tactical failure, but at the same time, it could be a strategic success: The other guy won today, but he killed himself doing it.
And, of course, there is always self-interest: To be accused of not thinking strategically is a definite career limiter.

But, is grand strategy an illusion? I think not! But, consider these pro-illusion ideas from a recent essay on just that point:*
"It makes sense to put stock in strategy if:
  • The [enterprise] has consistent preferences, if 
  • It can assess the costs and benefits of alternative courses of action (and make decisions more or less rationally), and if 
  • It has the capacity to follow through on its strategic choices.
But [perhaps] none of this is possible, and thus strategy is an illusion .....

In the complex and highly uncertain world of [big project and big enterprise] politics, it is all but impossible to identify the ideal strategy ahead of time. The [enterprise or project] lacks full knowledge about the threats it confronts, in part because [other businesses and markets] act [in private] and in part because their interests change over time. As a result, the consequences of [strategic] policy are consistently unpredictable.

The strategizing ritual contributes to a .... sense of insecurity. Psychological blinders, moreover, make strategizing still more difficult.
  • People suffer from all sorts of cognitive limitations that hinder decision-making—in particular, a tendency to rationalize. 
  • Instead of acting on the basis of ... beliefs, we revise our beliefs to make sense of our improvisations. 
  • We avoid identifying priorities and the tradeoffs among them.
  • Moreover, businesses are not unitary actors, and bureaucratic battles impede strategic planning and consistency.
This sounds like the "noestimates" version of "nostrategy": As a result, the consequences of [strategic] policy are consistently unpredictable.

I'm not buying the thesis that not thinking about a future that has a discriminating difference with the present is somehow a good thing. Just because -- the future is unpredictable with precision and there are unknowns and unknowables that will drive us off course -- is no reason not to tackle the hard stuff

*David M. Edelstein and Ronald R. Krebsein, writing in the Nov-Dec 2015 issue of Foreign Affairs

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Sunday, November 29, 2015

PMP exam is changing in 2016


Change is in the air, or at least it will be in the air next year as the PMP® exam is changed. Haven't heard about this? There's a 15 minute webinar put together by PMI that explains things pretty well.

But, you can get a 2 minute digest in this article that picks up the main points, to wit:
  • 11 January 2016 is the last day to take the test under the current version 
  • 8 new tasks within several of the existing knowledge areas have been added to the exam content outline. 
  • There is a shift in the weighting of the questions that you’ll get in the exam


Available now! The second edition .........
Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, November 26, 2015

Most projects run on "little data"


"Big Data" is the meme du jour, but most projects run on "little data", the sort of data that fits into the constraints of spreadsheets like Excel. It's everyday stuff that drives estimates, scorecards, dashboards, task assignments, and all manner of project analytics.

So, assuming you using Excel as a spreadsheet for doing actual calculations and data entry, and not a row-column table version of Word, you will find that you to do some analytics and data analysis from time to time.

Pivot tables are one spreadsheet data tool, but that's not the discussion today. Today, it's filters, which is the Excel name for the process and tool, but which the database people -- familiar with SQL for row by column -- would call a query.

And so, how to do a filter in Excel, something practical for the project manager? There are youtube's galore on the subject, but here's a neat, step by step, illustrated process that goes from the simple to the advanced.

Just what the PMO need to get into the data business

Some other rules
Beyond what you will read in the linked article, there are a few data rules that will make life simpler
  • Every column should have a header or title that is unique, even if just column1, column2, etc
  • Only one data value in a cell. Thus, first and last names should be in separate columns; so also city and state. But maybe also captain and ship's names. This is called "normalizing" the data
  • Keep the static data in separate row/column areas from the data that changes. So, if a ship sails to San Francisco on a certain date, the ship's description goes in one area; the city description in another; but the city/date/ship is dynamic and belongs in a third area.
  • Don't put 'word processing' paragraphs or labels in the middle of the data. In other words, maintain the integrity of row by column
  • It's good to have at least one column that is guaranteed to be uniquely valued in each cell, like a row ID
  • If you can avoid using "spaces" in the data, that's good. It makes the query more sure. So, "column1" instead of "column 1"
 

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, November 23, 2015

I was right before I was wrong


"The point of an investigation is not to find where people went wrong; it is to understand why their assessments and actions made sense at the time."

"... made sense at the time" to whom?  The investigation might want to look at whether what went wrong should have ever made sense to anyone -- what were they thinking?! -- and why someone was allowed to think it ever made sense.

I have in mind the Challenger accident of the mid-space shuttle era. Should anyone have been allowed to think that the solid boosters were safe after overnight temperatures in the 'teens? In that case the mix of politics, management, and engineering proved deadly.



Just released! The second edition .........

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog