Managing change or bullying change?

---

".. As [ ... ] has pushed toward [his assigned] goal in his first six months on the job, he has alienated faculty, state legislators and the student body. He has been accused of marginalizing needy students, shortchanging major departments and acting detached and even dismissive..."
 

The quote doesn't seem to describe your benevolent project manager, concerned for the feelings and well being of all those that are the target of change. To drive change, we are told to communicate, to actively listen, to compromise, and to give change a chance with a timely rollout, feedback, and adjustment, all over some reasonable and customary period.

But, one wonders how Tony Soprano might have driven change?

In any event, when the organization is scerolic, dug-in, culture bound, or just stubborn about losing what one may have worked a lifetime for, then the S1 style may be the only thing that works. Perhaps that is what [...] thinks he is facing.  I don't really know.

---

Source of quotation

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Big data... big ideas

---

Foreign Affairs magazine is not usually a tome of project management knowledge, but an essay on 'big data'  by Cukier and Mayer-Schoenberger caught my eye.

They write:

Using great volumes of information .... requires three profound changes ..... The first is to collect and use a lot of data rather than settle for small amounts or samples, as statisticians have done for well over a century. The second is to shed our preference for highly curated and pristine data and instead accept messiness:..... Third, in many instances, we will need to give up our quest to discover the cause of things, in return for accepting correlations.

In internet years, I think 'big data' is somewhere around 1994. So, there's a bit to go yet. But, forgive me -- did they say: "forget economically viable samples, accept messiness over accuracy, and be happy not understanding causation from correlation"?

One wonders if this pair have ever had to define "DONE" to the project sponsor?

I've done some pseudo-big data projects: data warehouse for a multi-billion $(revenue) company and multiple ERPs with zillions of millions of records. I never got away with 'messiness'. Somehow, the CFO, CEO, and all the other C's and VPs wanted to have assurance that business data was accurate... how quaint! When I was a business unit vice-president, I wanted accurate reports also. Who knew this wasn't needed?

However, I get it. Business is changing so project metrics may have to change as well. There may be a challenge fitting 'messiness' into the "technical performance measures" (TPM) or taking earned value on it.

And, certainly correlations instead of causality will start many arguments about "who shot John" and whether an improvement or a disaster can be laid at the foot of the project.

And, the economics of ever larger samples -- perhaps the whole population -- is going to come out of somebody's budget: there's no free lunch (data), even if user generated (See: Facebook)

---

KENNETH CUKIER is Data Editor of The Economist. VIKTOR MAYER-SCHOENBERGER is Professor of Internet Governance and Regulation at the Oxford Internet Institute. They are the authors of Big Data: A Revolution That Will Transform How We Live, Work, and Think

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

The man who did the job alone

---

It's not too often that I find something about project management in the chaplain corps, but hey... things emerge.

How often have you had a SME who was also a loner, eccentric, or just stubbornly independent?  No team for that guy! And, other times, we (not the SME of scorn of course) find ourselves working alone -- perhaps even choose to work alone -- even though we know better (See, for example, "pair programming" ). Either way,  I'll bet that this story resonates.

Here's a guy who never got the memo: 'Plans never survive first touch with reality'

The following is a letter a man wrote to his medical insurance company concerning an accident he suffered on-the-job. 

"I'm writing in response to your request for additional information. In Block No. 3 of the accident report form, I put "trying to do the job alone" as the cause of my accident. You said in your letter I should explain more fully. I trust the following details will be sufficient. 

I am a bricklayer by trade. On the day of the accident, I was working alone on the roof of a new six-story building. When I completed my work, I discovered I had approximately 500 pounds of bricks left over. 

Rather than carry the bricks down by the hand, I decided to lower them in a barrel by using a pulley which was attached to the side of the building at the sixth floor. Securing the rope at the ground level, I went up to the roof, swung the barrel out and loaded the bricks into it. Then I went back to ground level and untied the rope, holding it tightly to insure a slow ascent of the 500 pounds of bricks. 

Now -- you will note in Block No. 2 of the report form that I weigh 135 pounds. Due to my surprise at being jerked off the ground so suddenly, I lost my presence of mind and forgot to let go of the rope. Needless to say, I ascended at a rapid rate up the side of the building. 

In the vicinity of the third floor, I met the barrel coming down. This explains the fractured skull and the broken collarbone. Slowed only slightly, I continued my rapid ascent, not stopping until the fingers of my right hand were two knuckles deep into the pulley. Fortunately, by this time, I had regained my presence of mind and was able to hold tightly to the rope in spite of my pain. 

At the same time, however, the barrel hit the ground and the bottom fell out. Devoid of the weight of the bricks, the barrel weighs approximately 50 pounds. I refer you again to my weight in Block No. 2. As you might imagine, I began a rather rapid descent down the side of the building. 

In the vicinity of the third floor, I met the barrel coming up. This accounts for the fractured ankles and lacerations of my lower body. The encounter with the barrel slowed me enough to lessen my injuries when I fell onto the pile of bricks. Fortunately only three vertebrae were cracked. 

I'm sorry to report, however, that as I lay on the pile of bricks, in pain, unable to move, and watching the empty barrel six stories above me, I again lost my presence of mind and let go of the rope. The empty barrel weighed more than the rope, so it fell down on me and broke both of my legs. 

I hope I have furnished enough information about how the accident occurred. As you can see, it happened because I was trying to do the job alone." 

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Threats, big time!

---

Are you doing space projects? I've done a few, involved in various ways with lifter, payload, communications, range safety, and ground processing.

Now, when you do a SWOT to determine the strengths and weaknesses -- internal to the project -- and the opportunities and threats -- external to the project -- be sure to put JUNK on the threat register. Especially, space junk.

Check this out for the before/after plan:

There is an urgent need to remove orbiting space debris and to fly satellites in the future without creating new fragments, Europe’s largest-ever space-debris conference announced today.

The findings from the 6th European Conference on Space Debris were released during the concluding press briefing at ESA’s European Space Operations Centre in Darmstadt, Germany.

Future space missions must be sustainable, including safe disposal when they are completed. The current levels mean that we must soon begin removing debris from orbit, with research and development urgently needed for pilot ‘cleaning’ missions.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Motivation, and how to do it

---

Whether manager or leader, project manager or workpackage manager, there always comes a time to motivate people, even as they may be self-motivational in some circumstances. That said, is there anything new to report about how to do this?

No, not really, but Mike Clayton has pulled together the top twenty motivators in a nice posting that I bookmarked on Delicious.com for convenient recall

(Digression: I also use Evernote.com for a lot of sundry notes and stuff -- and Evernote is good for that sort of thing on mobile -- but I like Delicious for its facility to search all the other bookmarks by other subscribers)

Among the twenty are these four that caught my eye. Clayton calls them transformational motivations:

11. Mastery - becoming competent and then truly excellent at something is highly motivating - 'autotelic' means intrinsically motivating.
12. Growth - ...but even as a master, who wants to stand still - the opportunity to continue to grow is a motivator.
13. Purpose - but why do we want to master something and grow - we all need a purpose: to answer the BIG question: why?
14. Contribution - for some people the need to contribute is their purpose and for others it is a motivator that supplements their primary needs.

Of course, many have written about #11, Mastery. This is close to what celebrated author Malcom Gladwell (and others) have described as the 10,000 hour rule: until you put 10,000 hours into mastery, you're really not an expert.

However, I'm not sure I'd approach an motivational issue by pointing out that someone needs to get on with it because they have years to go to get 10,000 hours under their belt, and time's a wasting!

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Choking innovation?

The premise of agile teams is persistence: work like you train, and train and work together. These practices are the backbone of good benchmarks -- like velocity -- which is the heart of agile planning.

Then, of course, there is the counter argument: such familiarity drains the innovative spirit; there's not enough exposure to new stuff that comes with socialization -- it takes a village, etc.

And, then there's the counter-counter argument: with the right space planning, even persistent teams will wash up against many socialization opportunites from the lunch room to the rest room to the coffee bar (I don't think water coolers are much in evidence anymore, replaced by the K-cup machine)

So, is there a right answer: does persistence choke off innovation, or does the persistent team provide the vehicle to act on an innovative idea and get it into production more likely/more better?

I actually line up with the latter: persistence for quality benchmarking and effective work practices, but open plan work for the "osmosis of communication" as Alistair Cockburn would say.

And, of course, there's the Allen Curve that gives guidance on how "open" such open plan workspace should be. Innovation falls off dramatically (exponentially) with lack of socialization.

Generational differences

---

Yale student Victoria Buhler recently wrote a term paper that was recently  given some public airing. Some of what Ms Buhler wrote -- as described by columnist David Brooks -- is worthy of note by by project managers who have recruited young grads onto project teams, to wit:

• This graduating generation is very conservative in its appetite for change. Broadly speaking, they distrust the link between action and result.
• They require hypotheses to be tested, substantiated, and then results replicated before they commit to any course of action.”
• There is an obsessive focus on individual improvement: “Time not spent investing in yourself carries an opportunity cost, rendering you at a competitive disadvantage as compared to others who maintained the priority of self.”
• They wonder if the mathematization [sic] of .... policy performs a gatekeeper function; only the elite can understand the formulas that govern ......

The first one is project management 101: we are supposed to be experienced and capable of linking actions and results. Shame on us if this is an issue with a new grad on a project team. A good way to start is with an Integrated Master Plan (IMP) --

An event-driven plan that documents the significant accomplishments necessary to complete the work and ties each accomplishment to a key program event

This last one is particularly close to home for me. In the risk management classes I instruct for PMI eSeminarsWorld I ask about qualitative vs quantitative risk mangement and decision-making. I always get a big majority going with the qualitative. Students tell me it's just too hard to get everyone on the same page with numbers -- too much energy goes into defending the metrics and estimates.

Of course, we bring this on ourselves too many times, citing uncalibrated 'facts' that are not facts at all. When push-comes-to-shove, we often really can't defend the numbers.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Loyalty and Trust

---

From time to time, a profound thought strikes here at Musings. Today, it's a question:

Is it necessary for there to be trust in order that there be loyalty?
Can there be loyalty and simultaneously mistrust?

Spoiler alert: there's no right answer. It's a matter of your values and beliefs, for which there is no proof, validation, or algorithm.

So, where did this come from?

1. In my agile classes, we discuss the desirable/essential elements of leadership in the agile environment. The word trust comes up in almost every student reply; I don't recall 'loyalty' ever coming up (though I did search the archives), either as a quality looked for in a leader or expected to be given to a leader
2. I'm reading a new Winston Churchill biography. The biographers -- William Manchester and Paul Reid -- describe Churchill's relationship with Josef Stalin -- from 1942 onward when the USSR allied with the U.S. and Britain in WW II -- as mistrustful but loyal. I was really struck by that assessment.

So, back to the questions posed above; I think this:

•  I can be loyal to an institution (team, project, business unit, agency) without being trustful of its tactical leadership. However, if the mistrusted leadership is then strategic and becomes the strategy of the institution, then you lose me.
• At a personal level, I can't be distrusting and loyal to a person at the same time. At a personal level, trust and loyal have to go together.
• I think, without knowing, that WSC was loyal to the cause represented by the alliance with the USSR without being trusting of its leadership. I get it; it can work.

And, Mike Clayton has an excellent piece on 10 qualities of leadership -- but loyalty (given or expected) is not among them. So, another point of reference for those looking.

(Disclosure: I resigned an executive position in a large company when I could no longer trust a more senior executive and felt I could not be loyal to him, so that experience probably colors my thinking)

And, ONE MORE THING: you don't get the word 'respect' on leadership attribute lists. I wonder if trust-respect and loyalty somehow go together... could you possibly trust someone that you don't respect? Perhaps, one begets the other.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Agile in fragments

---

I've offered my opinion on "agile in the waterfall", but I'd not thought too much about agile in fragments, to wit: no co-location; little client participation; disjointed work; and low priority outcomes.

Sounds like a recipe for project failure for sure

However, along comes leadinganswers (a prominent agilist) with a piece entitled "agile for fragmented part-time teams". I had to read this one!

The main point of the article is that the backlog management ideas in agile can serve many project situations quite well, even those in which the project is part-time people doing "white space" tasks -- tasks of opportunity that fit in where they can.

There's hardly any commitment to schedule but that doesn't mean that there can't be a commitment to quality in whatever is delivered. And, it need not be software... backlogs work on hardware as well.

And, the agile idea that the team has to get together, even if virtually, on some periodic (schedule driven) or event driven occasion to review the bidding, progress, and problems also drives progress, albeit slowly.

There's more in the article, but the point is made: many agile practices can be used to good effect even if not in a contiguous and conventional project scenario.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

The CIA looks at 'big data'

---

Following up on the meme of the day, to wit: 'big data', I came across the GigaOM conference on livestream.com. (free login required) The conference is long over, but they posted videos of all their sessions dedicated to 'big data'.

If you're an old hand at (intelligence) collection, you'll see the differences immediately between the cold war era and today.

However, the main point here is to look at this through the lens of project management, particularly those of us who've done a data sensor/processor, data warehouse, or a large scale ERP. You'll see some of your project technical and functional issues nicely illustrated.

First, the "never throw anything away" data issue -- bigger gets ever bigger:

And this -- Tom Friedman's "The world is flat" platform idea writ large:

And finally about "sensors", this snip -- think of a sensor as anything that can gather business data, business intelligence, or business metrics -- and you'll get a feel for the scope of the idea:

It's a 30min video; if you don't have that much time, the slides are at businessinsider.com:

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Managing for value

---

One of my agile project management students said this:

My company will not allow us to start a job until we budget the revenue and plan for all costs. We are judged by how closely our projects come to the original planned budget.

To which I said this:

Being judged by the budget is being judged by input rather than output. Your sponsor will be disappointed often, even if you don't spend more than planned. Agile shifts the management to the value of the output which is far greater than the value of the input. Afterall, projects are a value multiplier: spend $10 on the project and get $1000 in business return, for example.

This whole idea of projects as a value multiplier -- as evidenced on the balance sheet if nowhere else -- is the theme of my most recent book (available in Kindle, ebook, and, of course, paper)

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Agile and the System Engineer

---

When we're talking about system engineering, we're generally talking about "The big three ideas for System Engineering":

• Requirements
• Architecture
• Validation

There's certainly nothing incompatible with the Agile Principles or the Agile Manifesto among those three.

Let it be said: We're from System Engineering, and we're here to help.....



Really? What can SE do for we agilists?

• Requirements: It's true that SEs are accustomed to structured analysis, decomposition, and lots of 'shalls' and 'wills'. Nonetheless, motivation to do requirements -- to develop not only a narrative from the many disparate statements, but to also fashion an architecture that supports the whole collection of requirements -- fits the agile need nicely.
  
  The big transition for SEs is making the move from a traditional 'shall and will' project to an agile project of conversational style requirements. Now admittedly, some SE can't/won't make the transition, but others will, and their skills are very applicable
  
  SEs are good at elicitation, modeling, risk assessment, and logic... all necessary ingredients when working with use cases and user stories. Hopefully, you're familiar with some of Scott Ambler's stuff on agile modeling, etc... all system engineering, all day.

• Architecture: A close cousin to requirements is architecture -- structure, interfaces, large scale design, and interrelationships. The big deal here is allocating requirements to the major objects, defining the object relationships, and adjudicating conflicts that would compromise coherence, cohesion, redundancy, and diversification.
  
  
• Validation: Validation -- checking things with the customer -- is not that much different, except for timing: more early and more often in agile compared to the traditional. But why SEs in the validation? Mostly, to bring the big picture and largest scale to validate the architecture (lower level validation is largely a team effort with various layers of release tests and integration tests). Such big picture stuff reassures the sponsor, gets marketing fully on board, and if there's to be manufacturing or post release support, then those entities can get on as well.
  
  You've probably seen this V-model if you're a regular reader. It's basically the SEs view of how the project comes down. Validation just completes the loop with the original narrative (shown here as the Concept of Operations)

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Lean in Orlando

---

Here in my hometown, they've discovered lean principles applied to construction:

The SkyHouse high-rise will top out in just a few weeks at 23 floors. If it stays on track, the building's 320 units will open ... only 13 months after the first dirt was shoveled aside. It takes that long just to build some custom homes.

The tower's builder, Batson-Cook Co., isn't pushing workers to rush; the job has gone quickly because of something called the "Lean" method, which is dedicated to ridding the construction process of waste, especially wasted time. Work schedules have been drawn so that nobody is left waiting on someone else

As the newspaper quote says, this project is going along in remarkably short time; and, the cost is reasonably under control.

And so what is the "lean method" applied to hi-rise construction? In this case the project manager adopted a unique schedule sequence for both task and resource.

The way we've always done it
The usual approach is to schedule each floor in a trade-craft driven sequence: first all the steel workers come in; then all the cement guys; followed by the plumbing and electrical, glass workers, and the like.

Another way to do it
In general, what they did was build each floor with parallel time boxes that align with different physical spaces, each time box/space centered on a particular trade. So, while the cement guys were working in one space on a floor in one time box, the electrical or plumbing guys were working on the same floor but in a different space in the same time box.

As one block was finished, the tradesmen (mostly men, but some ladies) rotated to the next block, and then up to the next floor. This makes for somewhat of a spiral planning method

The idea is that no trade is idled waiting for another. Each is fully engaged, so there's little loss to marching army expenses. The newspaper didn't say whether some Kanban system was incorporated for parts and supplies, but the supply chain had to be adjusted.... lot's of small lot deliveries. That may have driven the cost a bit, depending on how deals were struck.

Maybe Bent Flyvbjerg should come to town, take in the theme parks (no small feat of engineering, given the swamps they started with), and then see how downtown is done also

---

Bookmark this on Delicious

Check out these books in the library at Square Peg Consulting

Haptics: the technology of touch

---

Got six minutes to spare for viewing a TED video? Here's one that will add new words to your technology vocabulary, starting with 'haptics', the technology of touch.

Katherine Kuchenbecker is a mechanical engineer practicing at the University of Pennsylvania. She does experiments in haptics.

What's the big idea here?  To add a heretofore unavailable human factor to what we can already see and hear, to wit: synthesized touch.

This can be used to train those that work with their hands, like doctors and artists, about what something is going to feel like when they encounter it for real. So also rehabilitation of those with artifical limbs

And, ever stared through glass case in a museum and wonder what the object felt like? Just put you and on a senor pad to 'feel' the object. (Hand cleaner supplied separately)

If you're running an engineering project, you might hear words like these from your SME's
Tactile: referring to contact location, pressure, shear, slip, vibration, temperature
Kinesthetic: referring to position, orientation, force

If you like this TED video, you might also follow-up with this TED video, materials and technologies you might see in your next project (Caution: risk mangement required!)

• Building blocks that blink, beep and teach: (5:27) TED Fellow Ayah Bdeir introduces littleBits, a set of simple, interchangeable blocks that make programming as simple and important a part of creativity as snapping blocks together.
  For project prototypes, human factor experimentation, and putting down options, these may be a project winner    

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

The death of statistics?

---

Normal Deviate (thoughts on statistics and machine learning) is not a site I go to for the usual fare about project mangement, risk management, and the like, but with a provocative lead like "the death of statistics" I decided to read on...

As you might imagine, about the death of statistics we can say: Not exactly!

The issue seems to be all about the lastest meme, "big data" -- or in some quarters: "data science". With data warehouse projects and ERP projects, to say nothing of other "big science" projects (map the human brain?), project managers run into this stuff a lot. So, what is data analysis in the context of big data? What are we doing when we do data science?

These may not be the burning questions of the day, but we learn that Karl Broman -- who blogs at "The stupidest things -- statistics, genetics, programming, academics", is really wound up on this issue. He writes:

When physicists do mathematics, they don’t say they’re doing “number science”. They’re doing math.
If you’re analyzing data, you’re doing statistics. You can call it data science or informatics or analytics or whatever, but it’s still statistics.
If you say that one kind of data analysis is statistics and another kind is not, you’re not allowing innovation.
 

Of course,  Mr Broman got some pushback from some of his readers. In particular, we saw this reply from Hillary Parker at "No so standard deviations":

"OK but… as you point out, physicists do mathematics, but still call themselves physicists because that’s not all they do.
Whether or not you agree, data scientists would qualify themselves the same way — they do statistics, but also other things that statisticians generally do not do (product development, system administration, engineering, etc.).
 

I guess I'm with Ms Parker on this one... project managers do statistics (or get their project analysts to do stastistics for them) but still call themselves PMs or analysts....

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting