What is The Crux

Ever heard of the term "crux"?In mountaineering terms, it's the most difficult part of a climb.

Regardless if it's a climb or a personal goal, I see the start as the most difficult part.

I used to think that starting was easy and finishing was the hard part. I would now say finishing is hard, once you get started.

Do you keep putting things off, day after day, week after week?

Now that we've started a new year, what are you going to commit to? Almost as important, what will prevent you from getting started?

(the pic is from a trail map for the Sugarloaf Mountain trails that I've hiked)

Ready and Done

When leading development teams, I see most of the wasted activities happen during the development phase.  If work is not ready, before the team begins development, there can be delays waiting for clarifications from the business.  If acceptance criteria is not clearly defined, before the team begins development, work can go on and on trying to appease the customer.  What your team needs is a clear definition of "Ready to Work" and a clear definition of "Done with Work".  Though definitions vary from team to team and organization to organization, it's imperative that you do it.  It's also imperative the team writes the definitions, not someone in an ivory tower. As with all of our clients, I stress the need to have a minimal agreement on both definitions before work is started.  When defining both the entrance and exit criteria, all major parties within the team need to be involved, to lower risks that something will be missed.

Below are examples of the definitions or ready and done.  Notice that we consulted Analysts, Testers, and Developers.  For your team or organization, you may consult UX designers, DBAs, Architects or others.  Don't make your definitions overly onerous.  Just create something that is just good enough and go from there.

Example of a Definition of Ready

• Analyst – User story sufficiently defined and mapped from requirements

• Tester – Acceptance criteria developed

• Developer – User story is estimated and no known blocking dependencies exist within the sprint

Example of a Definition of Done

• Analyst – Working system reviewed and User Story accepted via Automated Test or Manual Inspection

• Tester – Test cases pass. All critical and high severity bugs fixed and other bugs identified and tracked

• Developer – Deployed to test environment and Code Review complete

So, what does your team require as part of your definition of ready or done? Do you have definitions?

As a side note, if you're preparing for the PMI-ACP exam, remember the team is responsible for the definition of done.

Image Sources: Pictofigo

Hawthorne Effect

The Hawthorne Effect is something I've seen numerousness times on projects.  When auditing or introducing a new process, do you tend to see people doing a better job than you expected? The Hawthorne Effect refers to the tendency of some people to work harder and perform better when they are participants in an experiment. Individuals may change their behavior due to the attention they are receiving from researchers, auditors, or coaches.

This effect was first discovered and named by researchers at Harvard University who were studying the relationship between productivity and work environment. Researchers conducted these experiments at the Hawthorne Works plant of Western Electric. The study was originally commissioned to determine if increasing or decreasing the amount of light workers received increased or decreased worker productivity. The researchers found that productivity temporarily increased, regardless if the light was increased or decreases. They then realized the increase in productivity was due to the attention given the workers by the research team and not because of changes to the experimental variable.

Do you audit your processes?  How do you ensure you get a true representation of project efficiencies and not suffer from the Hawthorne Effect?

HT: Wikipedia Like the drawing? Get it at Pictofigo

Parkinson's Law

When I was growing up, I was told the bigger the goldfish bowl, the bigger a goldfish would grow.  Keep the bowl small if you want to limit the goldfish size.  Thinking back, it's a pretty good metaphor for my understanding of Parkinson's Law.  The saying "Parkinson's Law" was first coined by Cyril Northcote Parkinson in his essay published in the Economist way back in 1955.

Work expands so as to fill the time available for its completion

This is what I see happening when developers or others have not decomposed their work to small enough chunks, in order to properly estimate their work.  The same goes with meetings if people don't stick to an agenda.

Yesterday, I saw a (vendor's) manager trying to break the Parkinson's Law.  Granted, I shook my head at his proposal but I admire the fact that he knows there is a problem and is trying to do something to correct it.

This manager has provided a (non-resource-loaded) schedule that has activities planned to conclude on September 30.  The customer is not happy because new work of higher priority has appeared since the vendor provided their 5,000 lined schedule, several months ago.  The customer does not have more money it can commit to new scope and they are unwilling to drop scope from the existing timeline.  Yes, we all know customers do this.  So, what was the vendor's proposed solution?  Going forward, all estimates of work (previously identified and baselined in the schedule) will now have 10% less time to complete. Since they never allocated any slack for activities in their existing schedule, this will become their schedule reserve. Don't ask me where they got 10%.  Tada!  Now they have time to complete more work.  Oh wait, you mean they shouldn't use schedule reserve in that way? No, they should not! And they shouldn't look at management reserve in that way either.  I know some out there are going to have a heyday with this.  It's not up to me.

I have to say, the vendor has done a very poor job with their predictive planning.  But who is to blame them?  It's not easy!  I've found adaptive planning to be much more accurate. That 5,000 line schedule was out of date the day it was published.  When I first looked at their estimates and later at their schedule, I new the efforts were grossly over-estimated.  But, both the estimates and schedule were accepted by the customer.  I do think the customer will now get more value for their money.

I got a kick out of the manager's response when someone in the meeting challenged him on the probability of people being able to complete the work in less time.  Though I'm paraprasing, his response was

It's surprising, if I tell people to have their work finished by Friday COB instead of Monday COB, somehow they just seem to get it done.

That is a clear indicator that people on his team did not do their own estimates and the original estimates were more on the level of a rough order of magnitude (ROM).  If it was my team, and I had made the same proposal, I would have had a revolt on my hands.  The difference here is my team estimates their own work, within a few weeks of actually doing the work, and we ensure the work is in small enough chunks that the customer can see something of value in a very short period of time.

What kind of goldfish are you?

1. Small goldfish in a small bowl? (small group, small timebox, small deliverable)
2. Small goldfish in a big bowl? (small group, big timebox, big deliverables)
3. Big goldfish in a big bowl? (big group, big timebox, big deliverable)
4. Big goldfish in a small bowl? (big group, small timebox, big deliverables)

Image: PPT Presentations

The Story of Monte Carlo

Once upon a weekday meeting, I had a story to tell.  It was the tale of a project manager, who’s name really rings a bell. He quantified the total project cost, he didn’t miss a dime. He also computed the schedule, he was always aware of the time.

He used all these input values, with random amounts being his friend. He ran these simulations.  I thought they would never end.

The outcome was a distribution, a bell curve if you like.  On the edges we saw some low points, in the middle there was a spike.

Monte Carlo was this fellow’s name, he was a heck of a numbers guy.  We asked him if he ever made things up.  He said he would merely quantify.

Now don’t think Monte worked alone, he had a counterpart.  Her name was Jane Stake-Holder, he worked with her from the start.

Jane could be quite demanding, sometimes ignoring project scope.  But Monte managed the situation well, knowing creep was a slippery slope.

His technique was well documented, a change would make everything slip.  He told this to Jane Stake-Holder who you'd think would do a back-flip.

But numbers don't lie and neither did he, Jane knew Monte would put up a fight.  She backed down and submitted a change request, the schedule would extend to the right.

Graphic: Pictofigo

Why You Should Use Common PM Language

I don't normally drink coffee from Starbucks but someone gave me a gift card.  I like black coffee, with no cream or sugar.  I like my coffee fresh so I order a small size.  So, why on Earth did the person behind the counter not listen to me? I ordered a small Caffè Americano. For those who do not drink coffee, that's nothing more than a small espresso and water.  My expectation was I would get a small cup of coffee.  When I looked at my receipt it said Tall.  I brought this to their attention and I was dismissed.  "Oh, it's the same thing."

Well, no, it's not.  Line up the cups and this is what you will see.  Extra-Small, Small, Medium, Large, and Extra-Large.  What does Starbucks call them? Tiny, Small, Tall, Grande, Venti. So, what I got was a medium.  I'm not going to split hairs here.  I'm trying to make a point.  There needs to be a common understanding between the vendor and the customer when you both define the same thing differently.  This is a financial transaction.  I want what I paid for.

How does this apply to Project Management?  From the customer's perspective, what is the definition of done.  From the vendor's perspective, what is the definition?  From every stakeholder perspective, do you all have the same definition of done?  You should!

It's important to note, it doesn't matter which approach you use.  Waterfall, RUP, Agile, or Kanban.  Everyone needs to understand and agree to what done means.

Risks and Benefits of Cost-Reimbursable Contracts

As I mentioned in my previous post, Fixed-Priced Contracts, there is no ONE best type of contract to manage. The risk the vendor and customer share is determined by the contract type. The best thing you can do is understand the risks and benefits of each. There are three categories of contracts: Fixed-Price, Cost-Reimbursable, and Time and Material (T&M). In this second installment of a 3 part series, I will define the contracts in the cost-reimbursable category. It will hopefully help you on the PMP exam and out in the real world.

Cost-reimbursable is a contract category involving payments (cost reimbursements) to the seller for all legitimate actual costs incurred for completed work, pus a fee representing seller profit.  Cost-reimbursable contracts may also include financial incentive clauses whenever the seller exceeds, or falls below, defined objectives such as costs, schedule, or technical performance targets.  Three of the more common types of cost-reimbursable contracts in use are Cost Plus Fixed Fee (CPFF), Cost Plus Incentive Fee (CPIF), and Cost Plus Award Fee (CPAF).

A cost-reimbursable contract gives the project flexibility to redirect a seller whenever the scope of work cannot be precisely known and defined at the start and needs to be altered, or when high risks may exist in the effort.  Frankly put, if the buyer doesn't know what they want, this type of contract allows the project to move forward without the risk to the seller.

• Cost Plus Fixed Fee (CPFF) reimburses the seller for all allowable costs for performing the contract work, and they then receive a fixed fee payment calculated as a percentage of the initial estimated project costs. The fee is paid only for competed work and does not change regardless of seller performance. The fee amounts do not change unless the project scope changes.

• Cost Plus Incentive Fee (CPIF) reimburses the seller for all allowable costs for performing the contact work and receives a predetermined incentive fee based upon achieving certain performance objectives as set forth in the contract. In CPIF contracts, if the final costs are less or greater than the original estimate costs, both the buyer and seller share costs from the departures based upon a prenegotiated cost sharing formula, e.g., an 80/20 split over/under target costs based on the actual performance of the seller.

• Cost Plus Award Fee (CPAF) reimburses the seller for all legitimate costs, but the majority of the fee is earned, based on the satisfaction of certain broad subjective performance criteria. This performance criteria is defined and determined by the buyer and and incorporated into the contact. The determination of the fee is based solely on the subjective determination of seller performance by the buyer, and is generally not subject to appeals.

Image Source: Pictofigo

Free Critical Path and Float Calculation Worksheet

Critical Path Float Calculation Worksheet

The number one search on the Critical Path website is for a Critical Path and Float worksheet.  Though you should be using software to calculate a critical path, if it is mission critical, it is important to understand the concept for the PMP exam. Rather then go into the specifics on how to calculate the critical path and float in this post, I'll merely say a free worksheet template  and PowerPoint presentation are available and you can download them at any time. (see links below)

•

Remember the Critical Path tells you the activities that can not slip a day without increasing the total duration of the project or moving the project completion date. It is the longest path of logically related activities through the network which cannot slip without impacting the total project duration, termed zero float.