Ah, simplicity.

We all seem to want it, but we rarely seem to get it.

Many experts have discussed simplicity and complexity. But their contributions often confuse various terms, which hasn’t led to a simplification of the discussion itself.

Here is my attempt to clear things up a little…

What is simplicity?

Simplicity usually relates to the burden which a thing puts on someone trying to explain or understand it. Something which is easy to understand or explain is simple, in contrast to something complicated. - Wikipedia

If you’re going to discuss simplicity, it is important to know the difference between complex and complicated. Not knowing the difference means you might apply exactly the wrong approach to the right problem. (Or, the right approach to the wrong problem.)

I believe the difference needs to be explained using two dimensions. The first dimension is about the structure of a system, and how well we are able to understand it:

• Simple = easily understandable;
• Complicated = very hard to understand.

The second dimension is about the behavior of the system, and how well we are able to predict it:

• Ordered = fully predictable;
• Complex = somewhat predictable (but with many surprises);
• Chaotic = very unpredictable.

The Structure-Behavior Model

My underpants are simple. I found it easy to understand how they work. But my watch is complicated. If I took it apart. it would take me a long time to understand its design and its components. And yet, neither my watch nor my underpants hold any surprises. (At least not for me.) They are ordered, predictable systems.

A three-person software team is simple too. It takes only a few meetings, dinners, and beers to get to know everyone on a team. A city is (usually) not simple but complicated. It takes taxi drivers years to know all its streets, alleys, hotels, and restaurants. And yet, both teams and cities are complex. No matter how well you know them, there will always be surprises. They are predictable to a degree, but you never know for sure what will happen tomorrow.

A double pendulum (two pendulums attached to each other) is also a simple system. It is easy to make and easy to understand. And yet, it undergoes unpredictable chaotic motion due to a high sensitivity to the initial setup of the pendulum. And stock markets are also chaotic. They are by definition unpredictable, or else everyone would know how to make money on stock exchanges, and the whole system would collapse. But, unlike pendulums, stock markets are also extremely complicated. The many different businesses and types of financial properties and transactions make them utterly incomprehensible for a simple guy like me.

Complicated refers to a system’s construction being too intricate to understand, unless you’re an expert, while complex and chaotic refer to a system’s behavior, which is unpredictable to a small or large degree.

What is complicated is not necessarily complex, like two cars in a garage. And what is complex need not be complicated, like two people in a bedroom. (But these people’s behavior in their bedroom can be quite unpredictable.)

• Simplification is the act of making the structure better understandable (moving it from top to bottom in my model.)
• Linearization is the act of making behavior better predictable (moving it from right to left in the model.)

Unfortunately, linearization is (in laymen’s terms) usually confused with simplification. And that’s where the complications start…

How Does This Differ From Other Models?

Cynefin is a model devised by knowledge management scholar David Snowden. It describes a typology of contexts using four domains: Simple, Complicated, Complex, and Chaotic, and is used to guide approaches to decision-making and policy-making.

However, Snowden doesn’t distinguish between the structure and the behavior of systems. This can make discussions a bit complicated (not complex).

Management professor Ralph Stacey created something similar, called the Agreement & Certainty Matrix. It shows Simple, Complicated, Complex, and Anarchy (Chaos) as four areas based in two dimensions: the degree of agreement and the degree of uncertainty.

This model suffers from the same problem. I don’t see complicated and complex as two discrete domains. Instead, I see them as parts of different dimensions. That’s why my Structure-Behavior Model identifies six domains instead of four. And some systems (like cities) can be both complicated and complex.

OK, Now We Can Revisit Simplification

I believe my Structure-Behavior Model is able to simplify discussions around simplicity, and to clear up some misunderstandings…

Everything should be made as simple as possible, but no simpler. – Albert Einstein

With this quote Einstein meant that a system must be made understandable, which means moving it vertically, from the top of the model to the bottom (simplification). However, his addition “but no simpler” maps to the behavior of the system. Einstein warned not to change the system horizontally, because that would change the kind of system (linearization.)

Simplicity is a myth whose time has past, if it ever existed. – Don Norman

In an inspiring article Don Norman discussed the value of having more features in a product, instead of fewer. More features means different behavior, and (often) also a different structure. In my diagram it is both a horizontal and vertical issue. (For example: Google just added Priority Inbox to GMail. This made GMail’s behavior more complex for me. It also complicated the user interface, but I still seem to understand it well enough.) Unfortunately, Don Norman used the term simplification both for linearization of behavior (horizontally) and simplification of structure (vertically).

And so Don complicated his message, which is exactly why many people didn’t understand him. Maybe it would have helped if Don had used pictures:

The goal of visual thinking is to make the complex understandable by making it visible, not by making it simple. - Dan Roam

In his bestselling book The Back of the Napkin Dan Roam suggests to use pictures to make things understandable by drawing pictures. He clearly refers to moving things from complicated to simple (vertically). However, his warning “not to make things simple” is, again, a confusion of terms. What Dan means is that pictures should not change the complexity (behavior, meaning) of something, because that would mess up people’s ability to predict what the pictures are trying to say.

And so…

Yes, by all means, simplify everything that is hard to understand!

But no, you may not want to linearize (“simplify”) something, because the reduced behavior of what you offer may not be what your user had expected.

Thanks for reading. I hope it was simple enough to understand.

Jurgen is an experienced author, trainer, and speaker. Why don’t you hire him to add some spice to your company event or seminar?

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
When You Are Rejected
Agile Is a Risk Management Strategy
Where There's People, There's Problems

Teamwork in a business sense can be difficult to for some people to get their arms around. As we increase the use of software teams – particularly as Agile development takes hold – understanding the nature of teamwork and what to expect is vital.

The book, The Wisdom of Teams: Creating the High-Performance Organization by Jon R. Katzenbach and Douglas K. Smith was published in 1993, but having read it recently I find that it has a great deal of insight that is applicable in today's teamwork-oriented approach of Agile software development. If you want to understand teamwork, this book can provide you an excellent primer on business teams.

What is a team?

"A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable."

Can you have large teams?

"A larger number of people can become a team, but they are likely to break into subteams. Large numbers of people have trouble interacting constructively as a group, much less agree on actionable specifics."

Here's a problem the book discusses that Scrum solves by defining the roles and protocols of team interaction:

"Team members must agree on who will do particular jobs, how schedules will be set and adhered to, what skills need to be developed, how continuing membership is to be earned, and how the group will make and modify decisions, including how and when to modify its approach to getting the job done."

The book makes note of key behavioral and mindset changes that must take place:

FromTo Individual accountabilityMutual support, joint accountability in addition to individual accountability Dividing those who think and decide from those who work and doExpecting everyone to think, work, and do. Building functional excellence through each person executing a narrow set of tasks ever more efficientlyEncouraging people to play multiple roles and work together interchangeably on continuous improvement Relying on managerial controlGetting people to buy into meaningful purpose, to help shape direction, and to learn. A fair day's pay for a fair day's workAspiring to personal growth that expands as well as exploits each person's capabilities
Finally, the book illustrates the Team Performance Curve, which traces the development of a team from the beginning stage of Working Group through the ultimate goal of becoming a High-Performance Team:


As a team moves from a Working Group that is nothing more than a collection of individuals towards a real team, the effectiveness of the team increases. The Potential Team is just barely coordinating its efforts, whereas the members of a Real Team have ceased to compete with each other and are working as a team, leveraging complimentary skills. A High-Performing Team maximizes effectiveness and impact due to their deep commitment to both each other and the business's needs.

While team effectiveness increases as you move anywhere along the curve, the performance impact can actually decrease as the working group transitions to an actual team. Moving along the curve and becoming both more effective in an impactful way involves patience, time, and commitment.

The project is in full swing; the project manager is so busy they cannot talk about the football match last night and was in early (again) today. The deadline for the procurement report (a significant part of the project) is a day late and you need it urgently.

Meanwhile, you notice the project team are relaxed, not too busy and to be honest, there are strong indications that team members do not have enough work to do.

You identify that the project manager needs to learn how to delegate.

Far from the truth? No!

Over the last 12 months I have had a lot of requests to train people how to delegate. Now you should bear in mind that these requests came during project management courses  that we run, not soft skills or management skills courses. Depending upon the time available I do one of two things:

•  give a handout which contains my 6 simple stages to effective delegation
•  use role play based around the 6 simple stages

So, what are the stages? They are:

1. The project manager needs to explain why the task or job is important and has to be done. It may be obvious to you why the task needs to be done, but maybe not so by project team members (including stakeholders) you are delegating to. They may not have been part of the discussions you were involved in. It helps to put the task into a context and helps to motivate the individual who does the task.

2. Define results you want very clearly so that the person understands what is expected of them. You may need to discuss the results with the person you are delegating to and re-visit part way through. An unclear steer from you will result in a missed opportunity. Check their level of understanding by asking questions

3. Define the authority the person has e.g. “you can decide on anything except for money.” Or, “any work that links into the south west team should be referred back to me.” Your role is to ensure the task does not go wrong but if it does, you must retain ultimate accountability i.e. you carry the can!

4. Agree a deadline when the task has to be completed - you may want an interim deadline such as let’s review this in 3 days and see how you are going - see also 6 below

5. Ask and get feedback that the person understands what is required. Check understanding with very specific “what?”, “why?” “how?” questions

6. Set up controls to review progress - bear in mind the level of authority given; be careful not to remove the authority you have given to the person www.deliverthatproject.com/main.html;ivering the task

Feedback I receive and Project Agency  Consultants suggests that this approach works! Try it and see how you go.

 

What It Takes To Become A High Potential IT Leader By Jim Anderson Although this article is not specifically targeted at Project Managers, PM Hut chose to publish it, as an IT leader can easily be/mean an IT Project Manager… What is it going to take to make your IT Leader career a success? Sure, you can deliver [...]

I have to endorse Bas de Baar's latest post.  Bas is right into the sociology of projects and his latest post is another great reminder abut the human aspects of projects.

var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try{var pageTracker = _gat._getTracker("UA-xxxxxx-x");pageTracker._trackPageview();} catch(err) {} var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try {var pageTracker = _gat._getTracker("UA-4191072-4");pageTracker._trackPageview();} catch(err) {}
Your relationships are more important than technical skills to both you and the projects you work on.   Sure, technical skills are both important and useful, but not nearly as important as your relationships with your team mates, customers and partners.

PlanDone has been around about two years, although the company says their concept for the software was formed in 1994.  It’s a cloud based, hosted project management tool with collaboration features.

At the top level of PlanDone you have projects, which are basically the high level goal you are trying to accomplish.  These break down into tasks, which further break down into action steps. The action steps are the bits you actually do.

When you log in you can see your projects and tasks on the left hand side.  You also have a ‘My Top 10’ dashboard, which shows the main things assigned to you, colour coded by order of proximity, so things due in a day or less are coloured red, for example.  This section breaks down what action steps need to be completed by you, and was included to help teams know what they should be focusing on – it’s an aid to prioritisation, which is useful if you have people on the project team who would rather do the cool tasks than the ones that are due tomorrow.

This does not have an element of workflow – tasks pop up into my queue and I don’t have the ability to accept or decline them.  However, I would get an email if a new task was assigned to me, or if a task was about to reach its deadline, which is another good function, as project team members don’t spend as much of their time as we do clued to tracking and reporting tools.

A project’s information page allows you to label it with keywords, store information about milestones, risks, assumptions, details on the project team, and so on.  It also has a ‘stats’ section at the bottom which shows you number of tasks, hours spent and progress as a percent complete, which is great summary, and really shouldn’t be hidden at the bottom of a long page under the ‘project goals description’ and ‘notes’.

It works on mobile devices, which is a great feature.  I also loved the ‘recent changes’ section which shows you all the stuff that has been recently added to the site in the form of a wiki.  The tool makes good use of colours by colour coding sections (the reports section is a lovely purple) so it is very easy to navigate and know where you are at any time.

Unfortunately, in real life it would be no good for me because it doesn’t yet have the capability to manage different currencies. And the Gantt chart is not very good at all.

Graphically, the Gantt chart view is attractive to look at.  But you can only see tasks and not the action steps. As the action steps are the bits that are assigned to people, I find that odd.  I also don’t like the way the dates are displayed, and if I remember rightly, you can’t change the date formatting.  This is another reason why PlanDone won’t travel well outside of the U.S.  We can understand the U.S. way of writing dates over here, but it does make things just that little bit more difficult.

Another positive from PlanDone is that they have put a serious emphasis on communication, and there are several ways that team members can work with each other using the software.

There is a comment feature that works much like blog comments – users can add a comment to a task or an entire project, and that sends an email to the rest of the project team.  They produce a pretty straightforward running tally of things that have been said – another point that the development team have given consideration to is the fact that you need to capture conversations, as well as just have them.  This is partly for the purposes of corporate policies, and partly because you need a way to remember what the team discussed three months ago.

There is a collaboration area which is wiki-based.  Everyone can contribute on the same page, and this can be shared with external parties without giving them rights over all the plans.

There is a related files area, which allows you to upload documents.  This saves having documents floating around on desktops or on inboxes, and means you don’t have to pay out for SharePoint.

Finally, you can see who else is online and chat with them.  The benefit here is you don’t have to rely on external chat software where your friends are constantly popping up asking your opinion on the latest YouTube video.  Apparently, this PlanDone chat keeps people focused on work – although of course it won’t stop them having Messenger open in the background.  You can save the contents of a chat session to a project or a task, or to the wiki.  I thought this was an excellent feature and it supports good e-policies at work too.

All round, PlanDone looks like a good tool.

Apologies for the poor screenshots in this post!

Related posts:

1. Software review: Viewpath Express Viewpath 2.0 is web-based project management tool.  Earlier this month the company announced at the Office 2.0 Conference in San Francisco that it was making...
2. Review of ConceptDraw Project 3 Setting up a project is easy: anyone familiar with MS Project will be able to navigate around without problems. The main part of the screen...
3. Review: 5pm 5pm is web-based, on demand project management software.  It looks lovely and the user interface is intuitive.  It’s very easy to get going and the...

When people ask me for one sentence summary of a great boss, I answer "He or she promotes both performance and humanity, and strikes a healthy balance between the two when trade-offs are necessary."   In Good Boss, Bad Boss, I quote a cool 2008 American Psychologist article by Mark Van Vugt, Robert Hogan, and Robert Kaiser who, after examining descriptions of admired and effective leaders in settings ranging from ancient human tribes to modern corporations and sports teams, conclude the best leaders are both "competent and benevolent."

In light of this perspective, I am intrigued with reports (see here and here, for example) about 54 year-old foreman Luis Urzua and the impressive steps he is taking to oversee, organize, protect, and tend to the emotional needs of the 33 men trapped in the mine in Chile -- a group that faces months trapped underground.  Urzua kept the men alive by immediately rationing food (two spoonfuls of tuna and a glass of milk every 48 hours for each man), which enabled them to survive and to avoid dysfunctional conflict until food started arriving through a small hole drilled be rescuers -- a crucial move because none the miners had run out of food 48 hours before despite the rationing.  Uruza has organized the underground space (he is a skilled topographer) into a work area, sleeping facility, and so on, and is keeping the men on 12 hour shifts by using the headlights of trucks in the mine to simulate daylight.  He not only needs to keep the group healthy and focused to survive the ordeal, he  needs to stay in control because, under some rescue scenarios, the men will need to remove many tons of rocks to help with their own rescue operations.

I was also taken with reports about the "leadership team" that has emerged.  The New York Times tells us that the oldest miner, 62 year-old Mario Gomez has "become the spiritual guide to his men, government officials said. He has organized a small subterranean chapel and is serving as unofficial aide to the psychologists working on the surface to cope with the miners' sadness and fear."  In addition, another miner, "Yonny Barrios, 50, the group's impromptu medical monitor. He is drawing on a six-month nursing course he took about 15 years ago to administer medicines and wellness tests that health officials are sending down through the 4-inch borehole and then analyzing in a laboratory on the surface."

This case is so striking to me because Urzua and his team have taken such impressive action to tend to both the performance and human needs of the group -- the blend of their competence and compassion is striking.  Moreover, if I go through the mindset of the best bosses discussed in the opening chapter of Good Boss, Bad Boss, the key elements are all there:

1. The men are being pushed by their leaders (especially Urzua) hard enough to maintain their discipline and order, but not so hard as to be overwhelmed (consistent with the notion that the best bosses strive to be perfectly assertive).

2. Uruza is showing extreme grit; in particular, a hallmark of gritty leaders is they treat life as marathon rather than a sprint,

3.  In related fashion, Uruza and his team -- and their advisers above -- are treating this ordeal as a small wins situation, where the final goal of escape (and not getting overwhelmed by this big hairy goal) depends on one tiny victory after another.

4. Uruza is clearly not suffering from detachment or power poisoning, as he is hyper-aware of how the large and small things he does affect the miners' moods, actions, and ability to survive; and he is not taking more goodies for himself than others.

5. There is no doubt that he "has his people's backs," that he will do whatever is possible to protect them.  One way that good leaders protect their people is by limiting outside intrusion, and you could see this mindset when he urged experts to keep the medical conference call short because "We have lots of work to do."

This is clearly an extreme situation, and you could argue that parts of it don't transfer well to the mundane organizational settings where most us work.  But I do think that extreme situations sometimes bring into focus what human groups need to thrive in terms of both performance and well-being, and what the best leaders do to help make that happen.  Indeed, I gleaned the five elements of the mindset of great bosses -- being just assertive enough, grit, small wins, avoiding power poisoning (and being aware that followers are watching the boss very closely), having people's backs largely from research and cases in ordinary and mundane settings.

P.S. For a take on how the miners can best survive this ordeal, check out this New York Times piece by psychiatrist Nick Kanas. 

I have been studying martial arts for the past year and a half.  I am not great but I am committed.

I was taking a private lesson recently.  I have been struggling during drills.  While I execute correctly much of the time, each time I execute a move I start analyzing it, even while I am executing the following move.

This proves to be a counter-productive approach.  I will often make mistakes in the following move because I am spending all my brain power thinking about what I just did right or wrong.

Estimating can have the same issues.  Data from past programs is useful. But we must look forward as well.  Differences in technology, requirements, program volatility, developers, and much more make just looking at the past a dangerous proposition. 

I still recall a magazine that once wrote of SEER “The journey is its own reward” meaning that the act of thinking about the program being estimated and understanding the range is issues and opportunities makes the program better and the estimates more viable. 

Each estimate shoudl look forward to what the program’s issues will be in addition to looking back to prior programs.  Yes, data is important, as indicated in the 10 step process.  And so is obtaining some understanding of the range of possibilities of the new system.

The following screenshot from SEER Metrics & Benchmarking illustrates the point.  After some analysis A new system is much more costly than nearly all the systems with similar characteristics.   Had we just used data and not done the analysis we would have severely underestimated the new system. The Journey is its own reward.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related posts:

1. The Price Is Right: Viable Estimates Produce Successful Programs
2. Step Two: Establish Technical Baseline, Ground Rules, and Assumptions
3. 10 Step Estimation Process Overview

Related Posts Computer Generated

• You Can Manage What You Can’t Measure
• The Sooner You Fall Behind, The More Time You Have To Catch Up
• The Estimate Maturity Model Can Improve Project Success
• Step Three: Collect Data
• Software Cost Estimation Is Like the BCS Ratings

Are Program Managers on the Career Path to the C-Level? By Gary Hamilton, Gareth Byatt, and Jeff Hodgkinson The debate on whether Program Managers would make effective senior executives is one that has gained attention in recent years. However, for this article we thought we would pose this question and contrast it with the muses of a [...]

In this discussion, I covered some quick tips to keep us moving forward.

The adage “you get what you expect” is true in many circumstances. But often times we are on automatic pilot, such that we are not aware that we’re making excuses for ourselves. We don’t realize that we are creating imaginary dependencies or that we’re even limiting ourselves by our practiced thoughts or beliefs.

These examples help illustrate this better:
Flawed Premise: It’s important to have a social aspect to meeting. It’s a way to build long-lasting networking and business relationship.

Because of this expectations our meetings cascade into other topics and take longer than originally planned.  We rarely achieve the actual purpose of the gathering.  The gathering actually turns into a “social event”.

This expectation is just an excuse to continue to have long-winded, ineffectual meetings.   Next time you are in a meeting, consider the following:

• Have a specific purpose and goal to your meetings
• If social interaction is an important aspect and purpose for the meeting, then explicitly place that on the Agenda with a time limit (time box it). OR announce/schedule a “15 minute networking” prior to the actually meeting starts.
• Have explicit agenda items that only support the specific purpose of this meeting
• If agenda items take longer than planned – place it on Parking Lot List and schedule it for a separate meeting
• If new items arise – place it on the parking lot list for separate meeting
• Do not cascade meeting from original purpose and follow your meeting ground rules.

Tip: Read my next blog on “Effective meeting management skills are not just for the board room”.  And let me know what you think of those tips.

Flawed Premise: I’ve been in this role for so long, that I’m only good in this one position.

Avoid (or maybe just realize when you are) “arguing for your limitations”. A more specific example would be:   Although I have some technical background, I’m not very technically deep. I don’t have a support background. I’m good at project management but that’s about it. I guess this is my niche.

You’re only limited by your imagination. In this example, this young lady is arguing for her own limitations. She only saw her current position as her only available option.
After some collaboration with her, she realized that (as a project manager) she has great management and communication skills. She can “read” people. She’s a good networker. She sees innovative and creative opportunities that others miss. She always wanted to move into a more strategic and design position. Because of her previous work with clients, she has the insight and background to design better client-performing products. In her previous client advocacy job, she networked with marketing, sells, clients, product managers and various product executives.  She is great at presenting the big picture to various backgrounds and levels. Even though her technical background isn’t of the level of a developer or coder, she has the product know-how and technical background to easily discuss technical issues at the business executives level and in a language that they understand. She has the perfect combination to be the liaison among the business executive (people sponsoring the endeavor), the sells force (people selling the product) and the developers (people coding the product).

The above description led to positions like “executive client manager”, “product manager that designs and defines product requirements”, “marketing manager”, and “operations manager to the VP of Development”. etc.  Once she focused on the essence of her skilled (instead of the title or role), she was able to better appreciate and articular her value to her company.   She was able to obtain a skip-level operational manager position for the VP of the international based company.

Tip: Having someone to discuss your career goals helps cut through some of the self-sabotaging talk we all deal with helps.

Flaw Premise: I can’t do this because I haven’t done that.

We often build our own traps via Imaginary Dependencies. An easy example, I need to go to bed early to get up early.  I want to get up early but I need 6 hours of sleep.

You can always get up early – independent of what time you go to bed. You may be a little tired during the day, but it will be easier to go to bed early that evening. This is an imaginary dependency.
If you go to sleep thinking that you will have a deep, relaxing, regenerating, surrendering, luxurious, long nap (regardless of the amount of sleep- ie quality versus quantity) and you are excited about what lays ahead in the next day – you will awake energized, refresh and ready for anything.

The above is a simple example, and many other excuses fall into this category.    Although we don’t want to intentionally create excuses, we sometimes can’t see them as such.

Tip: Get into the habit of asking yourself “Is this excuse REAL?” Be your own devil’s advocate (or find a friend that will).

Let me know if any of these ideas hit a cord with you.

Technorati Tags: Accountability, best-practices, common-sense, communication, project-manager

This video introduces risk management and how to mitigate it. Slides of the presentation

Mike Cottmeyer is focused on maintaining business agility while adopting team agility. He shares various techniques and strategies that are successful with larger organizations when adopting and adapting agile techniques. He also shares his experience helping people transition from traditional project management to agile project management. http://www.infoq.com/interviews/cottmeyer-on-agile-enterprise

Sorry, couldn't resist.

6 Principles To Avoid Project Screw-Ups By Lonnie Pacelli Project screw-ups mean wasted time and money and can irreparably damage your relationship with business partners if they perceive that you are at fault—in any way. If you’ve been through a post-mortem for a project that failed, you’ve likely heard one or more of these “we didn’t” excuses: “We [...]

Almost two years ago I wrote “El Grande Post”. Outlining “El Grande Vision about Projects, The Universe And Everything”. It was one of many attempts to explain projects, your mind, identity, culture and all other things human.

It was titled: “The Four Dharmas Of Project Management“.

Can you imagine? Four dharmas! Wow. How about I try to explain it in one go?

The essence is how our identities shape our environment.

This is how I think it works.

You have a perception of yourself. Your identity. A way to describe an identity is by group association. I am a Dutch, male blogger. That are 3 associations: male, Dutch and blogger. Some associations are by choice, some by birth.

You always have more than one group association. Basically, you can identify yourself with as many groups as you can imagine. Not all group memberships are equal: you can give one more priority over another. Emphasize one more than another. When I am attending an Internet related conference, my “blogger” identity is more important than being Dutch.

Amartya Sen formulated this perfectly in “Identity and Violence” (affiliate link): “Given our inescapably plural identities, we have to decide on the relative importance of our different associations and affiliations in any particular context.”

Your own perception is one part of this story.

We are more attracted to some people than others. We are more at ease with some than others. We like some people more than others. This is a personal thing. This is about perception: your perception of the other.

We pick up all kinds of cues from people. How they talk, what they wear, what they do, how their online profile is written. Based upon those cues we build up our perception. We associate people with groups. We are creating our version of their “identity”.

We all have an idea about how a 6 year old talks. If we hear a kid of that age talking about cars and ice cream, we are at ease. If he talks about the importance of emotional intelligence, we freak out. We create expectations based upon the cues we experience. If these expectations are met, we feel more comfortable.

The way you perceive yourself in a certain context, determines which social cues you put forward. This manifestation of identity works as a filter: people who like this particular “identity” get “attracted”, those who are not in tune with it, are not.

In this way, the perception you hold of yourself creates boundaries: some stay at one end, others cross.

Our plural identities help us change these boundaries. By emphasizing one part and downplaying another, by emphasizing deviancy, we can create higher or lower walls, change the positions of the boundaries. I am not talking about faking social cues hoping that people like you. I am talking about consciously deciding which part of your face to show.

So. Reflection. Identity. Cues. Boundaries.

This scales up.

If you put people into a group, if you have interactions between all the individual identities, a group “identity” emerges. A sense of “how we do things around here.” A culture. This group identity creates an attractor for “the right people”. It sets boundaries.

Now I get to the part I find hardest to grasp. Most difficult to explain.

It’s the personal identity, the mental perception of an individual that can determine the boundaries of an entire group. A team. An organization.

It’s the culture of a group that can enhance and nurture a persons identity.

How about that?

Speaking of culture. Last week I read an awesome piece about nurturing culture in an online setting: “Jumbled (but important) thoughts about culture.”

Image by Sister72.

Other people who liked this article liked these too

• Resilience Explained By Buzz HollingYou know: a project is just a bunch of people working together to achieve a certain goal. It is the ...
• Proud Postings: Project Shrink 2008The end of a year is always a special time. So, asking yourself questions should be allowed around t...
• Thin-slicing Project ManagersIn his book "Blink" Malcolm Gladwell popularized the term "thin-slicing". "... our ability to gauge...

Bas de Baar is an independent consultant based in the Netherlands. He uniquely combines over a decade of project and team leadership with nearly a decade online presence in the area of Project Leadership in a global and virtual world.

No More Dharmas. Or. How Our Identities Shape Projects.

Imagine a sailing boat with four guys onboard. They are all franticly working to make it to harbor. But they don’t have a map and they don’t have a compass. Can you imagine this scene?

And yet, this situation is not that different from the situation in which many software development teams are in today. Independent of software development or project method, many teams lack one or many of the following:

• A map which shows where they are
• A map which shows where they are heading
• A GPS which shows how they are progressing

Some teams have these tools but don’t update them that often. I’ve worked with projects where developers reported once a month. You can just imagine how long it took to act on a problem…

In order to act, you need to have quick and accurate updates – what is sometimes more dangerous than a map is a map which shows the wrong location (of you or the target) and if the update is a week old, chances are great that you act on the wrong stuff.

Besides having status updated, you need to keep it visual: a GPS or map is of no good kept in the pocket. If you don’t see the problems, you will still miss out opportunities to act on problems and also; if the status is displayed for everyone to see; chances are bigger that people will update their stuff to avoid questions.

My husband is now working on a digital tool to visualize progress. It’s built as a WPF application and is now based on Team Foundation Server (to visualize work items) but hopefully he will also include support for other data sources.

This pet project of his is called Virtual WIP (you guys into TOC or lean will probably get the word game) is very interesting and I hope to be able to implement this in an upcoming project. I guess many of you prefer analog tools, but working in an international organization, I need visualization which works long distance.

http://hakanforss.spaces.live.com/blog/cns!27CCB0417E50BA2/

His building of this application has gotten me (and him of course) thinking a lot about what you need in order to get us what sailors get from their maps and GPS:s. What would you need? If you have ideas, post them here or on Hakan’s blog.

All three of my children are students; my son and daughter are in college and my youngest daughter just started high school.  And I have been a professor for over 25 years, so I see lots of variation in how students -- undergraduates, masters students, and doctoral students -- go about trying to learn and be successful.  As such, I was struck with a list of 9 things over at BPS research that students can do to be more effective, gleaned from The Psychologist.  Check out the post at BPS research for details, but here they are:

1. Adopt a growth mindset: This might be the most important of all; as Carol Dweck's wonderful research shows, when people believe that their intelligence and abilities are malleable rather than fixed, they try harder of learn more.  It is useless and downright destructive to view your abilities as fixed because, if they are, why should you bother try? And failure means your dumb.  That mindset is dangerous nonsense -- and if your teachers start talking that way, ignore them --or send them some information about Dweck's research. 

2. Sleep well.  There is tons of evidence that sleep deprivation makes people dumber and nastier. There are times when you've got to push it because of deadlines and such, but I think we all know that feeling a dulled mind from lack of sleep. 

3. Forgive yourself for procrastinating.  A cool study shows that students who forgive themselves for past sins here procrastinate less and perform better in the future. 

4. Test yourself.  As BPS reports:  "A powerful finding in laboratory studies of learning is the ‘testing effect’ whereby time spent answering quiz questions (including feedback of correct answers) is more beneficial than the same time spent merely re-studying that same material."

5. Pace yourself. People remember things better when they do a bit every day rather than cram for exams. I know this is against the instincts and habits of many students out there, but the evidence here is clear, so learning to plod along can help you a lot.

6. Vivid examples may not always work best. This one is interesting because, as professor, I know that students love vivid examples.  But BPS reports some research suggesting that learning abstract concepts rather than the juicy stories that illustrate them enables students to more easily apply the concepts to diverse challenges.   (I have to learn more about this, as it actually seems inconsistent with stuff in Made to Stick -- although perhaps the challenge is that juicy stories are so sticky that we don't focus on the underlying lesson). 

7. Take naps.  I love this point. I talk about it a lot in Good Boss, Bad Boss because there is evidence that taking a nap not only makes you more effective, it helps keep your inner jerk from rearing its ugly head.  Napping is also a way to offset some of the negative effects of sleep deprivation when the pressure is on.  See the BPS summary of research on how to nap -- lying down is better than leaning forward, but leaning forward is better than not napping at all. 

8. Get handouts prior to the lecture.  I blogged about this research awhile back; many faculty now put handouts on line, so if you are a student, it sounds like looking at hem before the lecture and bringing them with you is a good idea.  Students who get handouts in advance take fewer notes, but still tend to better on tests, at least according to one recent study. 

9. Believe in yourself.  As BPS tells us:  "Self-belief affects problem-solving abilities even when the influence of background knowledge is taken into account. Bobby Hoffman and Alexandru Spatariu showed this in 2008 in the context of 81 undergrad students solving mental multiplication problems. The students’ belief in their own ability, called ‘self-efficacy’, and their general ability both made unique contributions to their performance."

I will send this post to my children; I hope they read it!  I would also add that if you look at this list, these tips aren't just for students.  Really, they are nice summary of the learning mindset, of how to manage yourself for learning over the long haul.  In particular, two overall themes jump out at me that are supported by piles of behavioral science research conducted under diverse banners (psychology, education, sociology) and labeled with diverse jargon:

1. If you believe you can, you can; if you believe you can't, you can't (points 1 and 9)

2. Treat your journey as a marathon, not a sprint or series of sprints (points 2,5, and 7; and perhaps some others)

Let me know what you think of these tips; and also let me know your ideas about how to persuade others to do some of this stuff!  I am especially concerned about the challenge of teaching people (and myself too) to "pace yourself."  That is something that is easier said that done.

10 Steps to Project Success By Michael Greer Step Results of Successful Performance Define the project concept, then get support and approval. A series of conversations, brainstorming sessions, and other formal or informal discussions about the project concept with your supervisor and key people whom you hope will provide project support An approved Project Charter Get your team together and start the [...]

A well known and very vocal Project Management instructor made a statement about Government Projects always being late and over budget. Then making a not so subtle suggestion that his competency based assessment approach, versus the PMI approach to certification, is solution to better project management.

Man, do I wish that was the case. Here's my hands on experience in the government (DoD, DOE, DHS) experience on the program controls side.

• Requirements changes impact programs in ways that are not desernable when first suggested. We see this all the time. "Let's make this change from one real-time control data bus to another real-time control bus for all the right reasons" - faster, better, cheaper. But then the second and third order impacts start showing up months later.
• Techncial architecture impacts are many times unknown. "Let's scale up the number of processing units from 20 to 100. It's only a 5 times increase, so let's up the cost and other impacts by 7 to account for unknowns. Turns out the real impact was not 7 but 14, twice what was estimated. Materials impacts, process flow impacts, the overall thermal impacts were huge impacts on the program.

The  processes used to manage a program are absolutely necessary for success. Earned Value Management, prorgammatic and techncial risk management, Systems Engineering, Measures of Effectiveness and Measures of Performance driving the Techncial Perfomance Measures.

But necessary of OK, what about the sufficient conditions?

• Senior management must behave in rational ways.
• Change control is mandatory, not as a "constraint," but as a process to reveal impacts
• All parts are connected, no matter what the suppliers say. A Systems Engineering paradigm is mandator for all things other then simple projects.

These, and many others, are not directly related to project management processes, even the general purpose ones found in PMBOK®.

At the bottom of this discussion the "necessary AND sufficient" conditions starts and ends with:

• Past performance,
• Extensive experience,
• Processes and tools, and
• The necessary leadership to put all this together.

Now how can we increase the probability of project success? This is the 64 thousand, 64 Million, and maybe 64 Billion dollar question.

Simple, and many times simpilistic soultions are just that simple and many times simplisitic.

We have to remember ...

For every complex problem there is an answer that is clear, simple, and wrong. - H. L. Mencken

There are no soltions to complex problems. Complexs are part of our current life paradigm. All the easy problems have been solved. So rarely will there be a problem that can be solved with a simple solution.

Project Management Should Not Be Written in Stone By Chris LeCompte Finding something that works — whether it is a process, methodology, or system — can be a defining moment. It means we have succeeded in our hard work to develop an approach that is in alignment with our core beliefs. If the quality of outputs increases [...]