Iterative work is human

Having read several great articles discussing Agile and Waterfall recently (e.g. More Agile Claims, What Killed Waterfall Could Kill Agile), I decided to share some thoughts. These days I’m involved in internal projects for “the business” (as opposed to “the ICT”). In a sense that IT components are part of a project, delivered by a an internal IT unit or an external supplier — usually with a dedicated Project Manager (obviously, every project is a “business” project, as it should lead to business benefits). Agile management hasn’t come our way yet. I wish it had (I know it aims at software development though).

Iterations are human. “Linear action” is the domain of machines, rather than people.

Take a look:

(If ‘A’ is the beginning of a project and ‘B’ — its end, it might be that iterations bring the team closer to the final product as expected by the client and his/her understanding of quality. The picture is a huge simplification — having in mind expectations, constraints etc.) We love to have a clear picture of where we’re headed. Describe it (business case, charter), plan it (aka make a prognosis) and then control it (or in many unfortunate cases – be managed by it). Having all constraints in place, it’s easier to put the damn thing on an invoice. Problem is:

Project Managers need time to grow as practitioners, as leaders. There aren’t so many experienced ones as one might think.
We have the tendency to reduce cognitive disonance in many ways — when things go wrong, only few have the skills and guts to let the world know “the king is naked.”
Not every environment leaves ample space for error and change.

Bottom line — people are not computers. They err, they fool themselves (“I don’t think this is so much of an issue yet”), they don’t always respond well to outside pressure (“By when exactly did you promise to deliver feature X?”). That’s why lean embraces errors and man’s imperfect nature calling it “continuous improvement.”

“if your #lean efforts are struggling, ask how much fear is in the org: fear of trying, fear of failing, fear of blame or punishment?” — Mark Graban from @LeanBlog

This is why I like the idea of iterations in any environment. Agile recognizes it, waterfall — not exactly.

* * *

Additional links

Tom Wujec: Build a tower, build a team – http://www.ted.com/talks/tom_wujec_build_a_tower.html

Don’t feel intimidated

If we are so knowledgeable, why is mediocrity omnipresent? If we consider titles, certifications and fancy tools, why do we still get more project failures than successes? Take a look at your own backyard — how are things going on there? Are projects on time / on budget? Are processes continuously measured and improved? Are you innovating? Does your company know what it knows?

You don’t need much to become better than the average.

Where’s the real value in using collaborative software?

I love software. I’m particularly fond of tools that aim to support teamwork, e.g. managing projects. Still, every now and then I ask myself: “Where’s the real value in using collaborative software?” — bearing in mind that geographically dispersed teams aren’t the most popular form of teamwork. Questions that come to mind:

Is software an excuse not to move people to a common location?
Are the business benefits related to buying the new tool sufficient?
Can my team do with a whiteboard and a good idea instead?
Is everyone ready to jump on the e-bandwagon?
What are the entry barriers for new users?
What if we decided to ditch the tool after some time?

Before getting too excited, it’s good to have the following in mind:

“To a man with a hammer everything looks like a nail.” (Mark Twain)

Focus likes less

We use contexts or tags in task-management because we tend to become overwhelmed with the number of things to do. If one has too many visible tasks to deal with, it is likely s/he will be less productive than trying to take in one or two.

A similar issue can be observed with project portfolios. Trying to juggle several dozens of projects will significantly slow down execution. Sometimes, when I see an organization struggling to eat an especially large “frog” (big & important project), I feel like suggesting:

“Leave just this one thing. And make it happen.”

Every New Layer Is Fat

A man’s capacity to add meaning to any virtual concept is potentially limitless. I wrote about this in an earlier entry — we love to create worlds. Corporations are often flooded by committees, sounding boards, functions and matrices. In one case, I encountered more than 40 (sic) committees in one such entity. Decision-making? Try making decisions in such an environment. Or perhaps… try putting words into actions: developing products, creating value, improving processes, reducing waste (well, at least there’s plenty of material to work on).

A safe assumption — every new layer is fat. Be it horizontally (silos, communication nodes) or vertically (e.g. organizational structure). Reduce, rather than add. Embrace, confront, rather than evade. Do not water down your decision-making ability by meddling with the two key organizational components:

communication
responsibility

It should be army-simple to be transparent and trustworthy. There’s no time to make it otherwise.

In a 1975 classic, The Mythical Man-Month, Fred Brooks discusses communication channels. Instead of using a thousand words, let me show you a picture:

Every new node increases the number of communication channels exponentially. When we reach ‘C’, problems are about to begin…

A Forgotten Quality

One of the topics in my project management trainings discusses PM personality traits & skills. During such trainings participants frequently voice qualities like:

communication
leadership (team building, delegating)
problem solving
enthusiasm
empathy
self-confidence
composure
etc.

… but one particular feature isn’t mentioned at all, though I feel that in the long run, it’s probably the most important of all — …

persistence.

In our world of a myriad choices, we do not instill a sense of discipline in our children any more. And how can they reach integrity without discipline? How can we do? How can they aim for mastery, learn (with the long term in mind), if they haven’t got the discipline to support their efforts? How can they commit to great causes which do not feel sweet all the time? How can they focus and grow?

I believe that a great manager should withstand all the weaknesses one can find in a team (and build on strengths). A great PM (any manager, for that matter) is a platform to incubate ideas on — and be sure he or she will not choose the exit door whenever things get tough. Persistence is key. As a matter of fact, the belief in a leader’s persistence is necessary to build trust, to talk about leadership at all.

Further reading

Such a Long Way

Make Things Happen

Those of us who work in projects are oft-times called “project managers.” Some find it even more appropriate to be called “project leaders.” Grace Hopper once reminded us that we manage things, yet we lead people. For the purpose of this post, let’s assume both of these relate to people. We manage people, we lead people. The question is — do we?

A sure thing about working in projects is that positions we deal with are in fact functions, resources we obtain are in practice temporary and… volatile, and our rights and authority as project managers — informal. Thus, when thrown into a project environment, we put on our heavy armor of project experience, shield ourselves with models and fire an occasional escalation or two to make things happen. After all, that’s what projects are all about, right? To make things happen.

When dealing with internal projects, in mixed operational-project environments, I’ve noticed that to “make things happen” PMs often have two choices:

To fight for a given resource or deliverable (winning a fight does not contribute towards the result).
To pitch up and complete the job on their own (completing the job contributes towards the result).

While no. 2 is not a safe bet, and many a time not an option altogether, the most successful project managers I’d come across in such environments were those who were willing to let go and do the job, provided they had the know-how. In a way — “to lead by example” instead of making a fuss. Escalations, worse — conflicts, take time. As project managers we are judged by the end result. Someone’s unwillingness to participate is rarely an explanation.

In a similar manner, we ought to go through obstacles responsibly, avoiding dispersed responsibility, taking this responsibility on our own backs when in doubt (avoid doubts).

Operations Hate Projects

lech: Very nicely put: “Most people do not resist change. They resist the uncertainty associated with change.”
wallybock: @lech Or they resist having change done TO them.

Operations

… are about the status quo. In general, it’s a false assumption (see process improvement), but in an individual’s mind that’s exactly how it works. “I am in claims handling, I manage claims from 9 to 5, 5 days a week.” “I am in customer support, I do…” “I am in logistics, I do…”

Regularly, repeatedly.

“My specialization requires focus on key activities.” Efficiency is the word of the day.

Repeatable (standardization)
Not temporary
Process

Projects

… are about change. Are [often] about imposed change. Are about dealing with the uncertain in [often|mostly] hostile environments. About managing risk, and stakeholders as if change itself was likely to be changed on the way. About fixing what’s “fix-able” — agreements, charters, initiation documents etc.

“Models are here to protect us. But experience shows, you must have your eyes wide open anyway.” Effectiveness is the word of the day.

Unique
Temporary
Product

Different worlds

Operations and projects are different worlds. Efficiency is about doing things right, effectiveness is about doing the right things (via Peter F. Drucker). But what’s more important, for efficiency to be efficient standardization is key (“I must do my job regularly well”), whereas effectiveness puts pressure on the end result (“I must deliver a result no matter what”).

What happens if you put these two together? If you’ve tried projects in mixed operations-project environments, then you probably know it too well. Projects are a blow to the organization. Let’s face it — operational employees do not like projects. They do not like to be “resourced” as it interferes with their “operating” (not to mention that multitasking is evil). Line manager – project manager conflicts are thus inevitable, and so are escalations, weak sponsors and “passing the buck.”

Can it ever work out?

@zpepe reminded me that environments are not always like that.

When we are a subcontractor working together with IT project representatives of an organization (IT departments are oft-times more project-oriented), when we are working with startups (startups are projects) or relatively small organizations. (Anything else comes to your mind?)

* * *

Is it possible to make projects fit seamlessly into “operational environments?” Or perhaps the dichotomy (operations vs. projects) does more harm than good and we should remove the word “project” from out dictionaries altogether and think “process” — no matter what.

Related:

Will Projects Cease to Exist?

Risky Thoughts

A couple of days ago a colleague from our Audit Department approached me during a training and asked me a question regarding risk management:

“Is there any weight added to “high”, “medium” or “low” for the “impact” column (or “probability”, for that matter) in the risk log?”

She mentioned that risk was something she was involved in more — in her present occupation, and she wanted to know, if there was anything quantitative below those values. I pointed her to m_o_r for starters — as an example of a more structured approach.

The simple answer to her question, however, was “no.” Without waiting a second thought, I added:

“I wish risk was identified -> estimated -> mitigation planned in the first place. It ends on theory level in many cases, yet any plan & business case without a [regularly reviewed] risk log to support our prognosis is a huge risk itself.”

When discussing the subject of risk, I often mention that our diligence as project managers most probably will depend on what the deliverable is. If this is a high risk project (e.g. an ascent of a high mountain or reaching the depths of the sea in a submarine) we will not treat the subject of risk light-heartedly.

* * *

On a similar note, but not directly related to risk management and risk logs, it really is better to find a way to add more meaning to the standard “low”, “medium” and “high” or “A”, “B” and “C” — either by adding a legend with more tangible information or, say, switching to “must”, “should” or “could” (but perhaps not in the context of risk).

Will Projects Cease to Exist?

I’ve got used to differentiating between operational work (“standing organization”, “business as usual”) and projects. But projects in mainstream business seem to be a fairly new concept (I’m not talking about construction work here). Yet, you find them everywhere – IT projects, process improvement projects, organizational projects. Projects seem to be another method to make better use of a company’s human resources. Or so it seems… If a person has “operational responsibilities” you can still put him or her on a project. If it’s a project function, unless you are doing time-tracking and Business Resource Management, the difference between a resource’s 50% or 300% on projects is just a matter of… numbers.

For many of us, projects became a synonym of change. These days, one starts to believe that before this concept was rediscovered in the western economy, progress was virtually non-existent.

I have the impression that projects aren’t so popular in Japan. The traditional approach, Kaizen, is more about small, continual improvements rather than bursts resulting from additional, project effort. Why is that? Why does Toyota strive to create the best basis for small, numerous improvements, to make it as easy as possible for everyone, instead of spending zillions on projects? Do we miss something here?

“Integrity comprises perceived consistency of actions, values, methods, measures and principles. (…) A value system may evolve over time…”
Source: http://en.wikipedia.org/wiki/Integrity

I believe that integrity is about balance. About small improvements in a generally strong, consistent system.

I cannot provide a certain answer to the question posed in the title. But I am very much aware where projects came from and where they are indisposable (construction industry). I’m not sure their grounds are equally solid where I see them now.