The server ate my homework

The server ate my homework! In a recent article, I learned that some schools are taking big steps and making wholesale changes to introduce technology in the classroom. Here I find out that students do work on laptops--provided by the school--and in real time teachers track progress and problems on a linked iPad. Now that's interesting integration!

On the other hand, that's a lot of change management, and a lot of change management for what is commonly thought of as a bastion of traditionalism: the K-12 teacher corps.

If successful, whatever is in the water should be bottled and given out to every ERP project. Lord knows that industry could profit by the examples given in the classroom transitions.

Perhaps this was never more true:

If you can't make the trains run on time, do away with the trains

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Value stream mapping

Value stream mapping seems to be a new label on old wine. But nevertheless, the wine ages well. In the old days, we simply called it process mapping.

Value stream mapping derives from the Lean community, where of course the focus is on leaning out non-value add. So, in value stream mapping, each activity, to include the workflow of authorization and other governance, and ancillary activities, like a trouble report or a status report, is evaluated for value-add.

And, of course that begs the question: what is value-add? There is an answer, of course, but it may take a bit of customization to make it work everywhere. Simply put: anything that is ultimately delivered to the customer or makes the customer deliverable a good thing in the customer's eyes.

A lot of governance would not fit this definition directly, but most indirect activities don't. Nevertheless, most practical organizations can't live without them, so there's a certain non-value overhead that goes along with everything.

One thing I do like about value stream mapping is the clarity of the diagramming. Take a look at this diagram:

If you're interested in more, this diagram came from a nice post at LeadingAnswers

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Messy information systems

Do you buy this idea?

... science-based, method-driven approaches can be misleading. Contrary to their promise, they are deceivingly abstract and removed from practice. Everyone can experience this when he or she moves from the models to the implementation phase. The words of caution and pleas for ‘change management’ interventions that usually accompany the sophisticated methods and polished models keep reminding us of such an implementation gap. However, they offer no valid clue on how to overcome it…

Does this mean you have to see it to believe it, or does it just validate the ideas of progressive elaboration (defined in the PMBOK as continuous improvement and refinement) or emergence (unpredicted--though perhaps predictable--interactions of system elements that become known)--or neither?

No matter how you go on this, you might like the book review of "The Labyrinths of Information: Challenging the Wisdom of Systems" by Claudio Ciborra as reviewed by EightToLate

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

The project sentence

Richard Feynman is a renown theoretical physicist (deceased 1988).

He once said that if he had to summarize modern science in one sentence he would choose: "The world is made of atoms".

Brian Greene, also a theoretical physicist, has written of Feynman's choice: "When we recognize that so much of our understanding of the universe relies on the properties and interactions of atoms......we can well appreciate Feynman's choice for encapsulating our scientific legacy."

And, there are other sentences. Many have said: "The business of business is business", meaning customers are swell, but shareholder value is better!

So, what about a project sentence? It would be great it would unify the three great values of project management:

1. Customer value (value as experienced by the customer)
2. Business value (value returned to the business as a consequence of project activity), and
3. Earned value (a measure of the effective utilization of the business resources committed to the project)

And, it would be neutral on plan driven vs outcome driven (agile)

So, how about this?

The business of projects is to effectively invest business assets to return to stakeholders value from the affirmative vote of customers

Brian Greene: "The Fabric of the Cosmos"
Photo

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

About change

Change is the price of survival

Gary Player

Professional golfer

Bookmark this on Delicious

PMBOK Software projects practice standard

LeadingAnswers has a nice summary of the motivations behind the practice standard for software projects now being put together by PMI. It's barely an outline now, but it will soon be joining the other practice standards that are either unique to an industry or to a domain, like construction and US Defense Department.

Here's a look at some of the issues to be addressed in the words of LeadingAnswers:

• Specification problems – software projects are hard to define because they are intangible and hard to reference.
• Evaluation Problems – We really need to see and use software to say if it is suitable for us, reading a spec is a poor method for validating functionality. IWKIWISI – I Will Know It When I See It applies.
• Knowledge Worker domain – we are using subject matter experts to collaborate and share information rather than industrial works to repeat a defined process.
• Speed of business change – system requirements change frequently as businesses evolve and change. Change rates are higher than in many other project domains.
• Building with bits and not atoms – we are manipulating information and models not concrete and steel so our processes and controls need to be different.
• Non-Linear progression – progress is often non-linear. Some things go quickly some things take a long time. Approaches that assume a linear progression to completion are more problematic to apply on software projects.
• Uncertainty – We have more technology uncertainty and requirements uncertainty than many other industries and so need more tools to checkpoint and adjust if necessary.
• Extreme modifibility – unlike physical construction where is difficult to move a bridge upstream when it is 75% complete, there are some changes that can be done late in software projects that have few parallels in other domains.

Here's my take: Software projects are "idea" projects. They are almost without boundary, both internally and externally. Not entirely of course: where the software meets the hardware, there is a boundary to be sure, especially if you are developing for an embedded processor, like a guidance computer in the tip of a weapon.

About ideas: ideas have no natural limitations: we all know that; it's unreasonable to imagine all ideas are ever known; ideas are volatile; ideas emerge and evolve with experience; ultimately ideas drive vision; and vision is the source of business value.

So, software projects are always going inherit the basic properties of ideas. As such, we need methods and management paradigms like agile to deal with ideas.

At the same time, projects more often than not spend other people's money (OPM). When you are responsible--and, gasp!, accountable--for OPM, your whole perspective changes. Order and predictability become very important.

A marriage of enterprise management skills and agile management skills perhaps is the answer. Anyway, that's what I been saying for a few years now.

Bookmark this on Delicious

Gladwell on intuition

“A tremendous amount of expertise lies in the unconscious mind ….. Anyone juggling many different variables, dealing with incredibly new and complex issues, … has to, at some point, rely on this body of submerged knowledge to make sense of their tasks”

Malcolm Gladwell