PM Effectiveness - The Experience Trap

Experienced project managers can deal more effectively with complex software projects”. Really?

This “conventional truth” is contradicted by INSEAD professors Sengupta and Van Wassenhove’s research on experience-based learning.

They tested the skills of hundreds of professional project managers using a computer-assisted game, built from professor Abdel-Hamid’s renown simulation models for software development. The game was configured to represent a complex environment and most participants confirmed it replicated real-world project situations.

Some of the research results and conclusions are reported in the article “The Experience Trap“, published in the February 2008 edition of HBR magazine:

• experienced managers don´t outperform less experienced ones;
• replaying the game didn´t improve their performance;
• most managers believe project size underestimation and consequent quality, timing and cost problems are recurring flaws in complex projects.

According to the authors, many experienced managers are trapped by their rigid mental models to repeat intuitive and successful behaviours they learned in earlier and simpler projects. The same behaviours can be ineffective or even counter-productive in more dynamic and complex environments.

Research on project management effectiveness is relevant to both individuals, organisations and institutions. Leaders in the professional community, like SAP’s Paul Ritchie, have been highlighting and reflecting on the article main points.

I agree with the colleagues that don’t accept high failure rates nor unsurpassable barriers to continuous learning and professional evolution.

At the institutional level, it is important to emphasise the need of more complete skill sets or more adaptable methodologies. At the individual level we must address the central theme of the HBR article: how can we expand our learning possibilities and build management expertise from our professional experience? In this context, I think the most relevant aspects of our professional practice are:

• How we think. Where does our thinking style enables or constrains our perception and learning capabilities?
• How we learn. Do we consciously and actively pursue learning from experience?
• How we position ourselves in the project and organisational context. Are we leaders or order takers?

Let’s explore these topics on the next posts on Project Management Effectiveness.

This article was originally published at Better Projects.

Picture thanks to Włodi@flickr.

The Trust Requirement

Intelligent dialogues require trustful relationships.

In the previous post “Most Requirements are just Design Decisions”, we invited BAs to rethink the rigidity of software requirements.

Relevant environmental changes or new knowledge should trigger corresponding requirements adaptation. Leading this process, a BA adds more business value to their organisations.

Unfortunately, requirements are just requirements for many BAs. They don´t have the opportunity to participate in the intelligent dialogues where strategic design decisions are made.

Effective collaboration between the IT function and other business functions can be a complex and difficult issue in many organisations. This represents a critical credibility problem that must be addressed both by IT executives and IT professionals.

The perceived credibility of an IT professional goes beyond his or her personal competence and integrity; it is grounded in trustful relationships.

Principles

Now I invite you to reflect on your professional relationship style. Is it effective to create and nurture trustful relationships? Here are some principles I have used over the years with good results.

Be a Good Citizen at Workplace. Genuine citizenship behaviour means to me to actively respect all fellow professionals and executives and foster a positive, constructive and productive work climate.

It is also important to have a clear view of what is bad workplace behaviour. David Maister highlights “20 bad workplace habits” from Marshall Goldsmith´s book “What Got You Here Won’t Get You There”.

Reach Out and Touch. Try to see where you and your clients fit in the whole picture. Be open to learn, understand and appreciate their values, interests and the language they use. Then, get closer to them.

Promote Dialogue and Empowerment. I found myself many times eager to present solutions to users as soon as I grasped the most salient problem issues. I learned through experience that rich and frequent dialogues are key elements for more fun and effective processes, that generate better quality solutions and results.

Give Consistent Care. Respond quickly, reliably and honestly to your clients demands. Make sure you consider thoroughly how all your actions will affect their actions. Always be in the front with your clients during major software transitions.

Do these principles resonate to you?

Share with us your thinking about this critical issue for our profession.

I thank Raven Young for indicating David Maister´s post, that inspired me for this post.

This article was originally published at Better Projects.

Picture by Think Panama’s photo stream. Original at Flickr.

Most Requirements are just Design Decisions

The language we use both reflects and influences our thinking.

The term “requirements” has its roots on bureaucratic thinking, that supposes a static and impersonal business world where specialists would be able to uncover, extract and document the definitive specifications for software systems.

Jeff Patton in his post “Requirements considered harmful” alerts us that most requirements are just design decisions. He shows how typical behaviours like asking and giving requirements can be dysfunctional because they justify avoiding responsibility and stop collaboration on a critical success factor for software development projects.

Recognizing that most requirements are just design decisions, gives us a better chance to design and deliver more effective software solutions if we (a) carefully treat them as design products and (b) are ready to adapt them quickly to new circumstances.

Carefully defining requirements as a product of a design process means we should (1) use a collaborative process involving all relevant stakeholders, (2) reflect about the requirements under different perspectives: market, business, users, system and (3) use the most adequate tools and language to express the requirements in a common framework comprehensible to everybody in the team.

Being ready to adapt the requirements means being agile to sense and respond to relevant environmental changes and being open to incorporate new knowledge generated by the organization. The capability to learn and innovate, quickly adapting and creating changes is critical for leadership in the marketplace. Business software should enable these changes and not prevent them.

I know there are situations where requirement changes are beyond our sphere of power and influence. However, as responsible professionals, we should not just let requirement decisions hide under processes, documents and signatures. It is healthy to foster reflection on the what and why of software requirements. As Business Analysts, we should lead this process and help our organizations expand their possibilities.

This article was originally published at Better Projects.

Picture by Lindsey Lissau. Original at Flickr.