We motivate businesses to be human

Archive for Project Management

PMI’s New Agile Certification: Good or Evil?

There are some who consider PMI “evil”, others strongly believe in PMI.  Now comes PMI’s new Agile certification.  As much as skepticism about PMI’s past philosophy of linear, traditional project management is justified, the new certification is a huge milestone for PMI, for the Agile community and for project management in general.  Given its global reach PMI will help spread the word and practice of agile project management.  This cannot be a bad thing. Just the opposite is true.

Whether or not a certification proves that he or she is truly capable of managing or working on an agile project, is another question.  It does show that the person has successfully passed an exam.  Where the PMI certification is more promising than others is the prerequisites to register and take the exam in the first place.  The candidate has to prove his/her actual experience in the agile world prior to taking the exam.  Personally, I think this is a much better approach than letting people take an “exam” after a 2 day seminar and then call themselves “master”.

In short, a certification is a label; and, it can be much more than that it is paired with actual experience and the right attitude to agile.  I am somewhat optimistic that PMI’s new certification will help serve the latter purpose.

Posted in: Agile, Project Management

Leave a Comment (6) →

Effective teams don’t need collaboration tools. Really? [includes podcast and presentation]

Last February I had a chance to attend (and speak at) the NASA Project Management Challenge in Long Beach, CA. In a session about collaboration tools one of the attendants claimed that “effective project teams don’t need collaboration tools”.
I admit that this statement made me think. I am interested in your opinion about this provocative hypothesis:

  • What collaboration tools do you use in your teams?
  • What can you recommend?
  • And what impediments have you been faced with and how did you overcome them?

To give you an idea about my own thinking listen to a recent podcast http://tinyurl.com/63wj84a or attend my presentation at the upcoming PMI Global Congress EMEA in Dublin, Ireland (May 9-11, 2011).

My presentation at the PMI Global Congress North America 2010 in Washington, DC, on the possible pitfalls of introducing collaboration tools  is available at Slideshare.  Click here to view and download a copy.

I am looking forward to your comments.

Posted in: Keynotes, Project Management, Tools

Leave a Comment (4) →

Refreshment for weary agile teams

In a recent article on the website of the Scrum Alliance Bob Martin addresses the problem of Scrum teams which after a period of hyper-productivity faces declining productivity and team morale.  His article aims to lay out a possible path back to high-performance and great outputs and client delight.  The key he claims to get the team back to a stage where it can go fast and stay clean.  And, he continues, both productivity and the output have to be measured.  He suggests to utilize engineering practices of eXtreme Programming (XP) such as Test Driven Development (TDD), Continuous Integration, Pair Programming, Collective Ownership, and Refactoring.

So much can be said: Bob’s article is convincing.  It is important that we need to keep our teams go fast and stay clean.  However, is measuring productivity and rewarding teams at the core of re-aligning flagging teams?!  I don’t think so.  What I think causes declining productivity and a deteriorating team morale along with lower quality deliverables is often an imbalance of the factors that ensure project success.  Let me tell you what these factors are and how you can find out if your own team fulfills these preconditions for success.

First, the team needs to have a common understanding of the project vision.  A project vision goes beyond project objectives or in the case of Scrum it goes beyond the Sprint or Product Backlog. A vision defines the purpose of the project or product in the first place.  We all know that requirements change throughout the lifecycle of a project.  The vision is less prone to changes.  The key is that the team understands and lives the vision.  For this to happen they need to be able to relate to the vision in its daily project life.  It needs to motivate and drive their activities.

Second, effective collaboration is not static.  It needs to be nurtured.  Just because you have a performing and hyper-productive team in one sprint doesn’t guarantee that this will go on forever.  Collaboration has to be nurtured on an ongoing basis for it to bear the desired fruits which is a high-performance team.

Third, performance is important and it needs to be promoted.  This is where Bob’s list of engineering practices comes in very handy as they help promote performance on the individual and team level.

Fourth, ongoing productivity and performance require reflection and continuous improvement.  Create a culture of learning in your team.  Often teams neglect proper regular retrospectives or lessons learned sessions.  The momentum and excitement of the beginning have flattened.  In such a situation I recommend to bring in an outside person to facilitate a lessons learned workshop and review the work of the team.  It is necessary and laudable that the team holds regular retrospectives.  This is no substitute to conduct external project reviews.  Provided they aim to identify ways and means to boost productivity and performance of the team.

Fifth, ensuring ongoing results should be a given in any Scrum team.  But is it really?  How tangible are our deliverables?  And how much value to they add to the customer?  Do they really delight the customer?  Have we lost touch with the customer?  Are the deliverables in sync with the overall vision of the project and/or product?

All of these 5 principles have to be balanced.  It is not that there is one principle which is the most important one.  They all have to be balanced.  And it is up to the team to do so.  If the team cannot see the trees in a forest, someone has to stand up to this task.  It is a question of leadership and it is a question of success.

To learn more about what it takes to re-align a weary scrum team, read book “Leadership Principles for Project Success” (CRC Press, 2011) or contact me directly.

Posted in: Agile, Book, Leadership, Project Management

Leave a Comment (0) →

Go and find your “Wow” project

One can find endless examples of projects. Tom Peters (2007) goes as far as claiming that all white collar work these days is and actually has to be project work. “And not just any project, no matter how droning, boring, and dull, but rather what … I come to call ‘Wow Projects’: projects that add value, projects that matter, projects that make a difference, projects that leave a legacy … ” (quote from “The Wow Project.” FastCompany, 2007. http://www.fastcompany.com/magazine/24/wowproj.html).

As I am getting closer to the end of an interim management engagement these days I am asking myself if the past months fulfill the description of a “Wow” engagement.  Luckily the answer is “yes!”
Throughout my career I was fortunate that most of the projects I worked on or managed, inside and outside of business, met these requirements. It was not the nature of the projects. It was the attitude of the whole team and its desire to create something special.
All of my wow projects started with a clear vision; clear enough to become emotional about it. We could see, smell, and feel the expected end results. This was a strong driver in our day-to-day activities. Other attributes of these projects were that collaboration was working: roles and responsibilities were defined, team members’ expectations articulated and accounted for, and all were reviewed regularly, adapting them where necessary. We nourished teamwork and the freedom to act for a common goal. Creating and nurturing an innovative learning environment, an atmosphere where feedback was sincere, honest, and constructive, was another success factor. It was about helping and learning from each other. Last but not least, the wow projects were about delivering results, not just the final deliverable. Instead, we set weekly goals to work on and deliver. This meant we always had a good sense of accomplishment. Project success became success for all of us.

Hence, while it is to early to tell where my next engagement will lead me, one thing is for sure, it will be another “Wow” project.

To learn more about what it takes to set-up, lead and manage a “Wow”-project and/or engagement, read my book “Leadership Principles for Project Success” (CRC Press, 2011) and/or contact me directly.

Posted in: Book, Project Management

Leave a Comment (0) →

Creating high-performance contexts for teams

According to Charles J. Pellerin high-performance contexts for teams have the following characteristics:

  • Mutual respect, people feel valued
  • Reality-based optimism, commitment
  • People feel included, trustworthy
  • Clear organization, accountability

In his book How NASA Builds Teams: Mission Critical Soft Skills for Scientists, Engineers, and Project Teams. (2009, published by John Wiley:  Hoboken, NJ) Pellerin describes the underlying structure of this context.  Alas, where his book falls short is explaining how to create the right environment for teams to prosper, especially in a project environment.

It is great to work in performing teams.  It is indeed a wonderful experience when you see how team synergy effects help the team achieve extremely high level of productivity, quality and results AND have fun at the same time.  It is magic.  However, it takes more than the insight of the key characteristics of high-performance contexts for teams.  The following 5 principles help as a guidance to project success:

(1) You and your team have to build and follow a common project vision.  It drives the whole team.  It may be ambitious but feasible. It certainly motivates the whole team to commit all its energies to achieve it.

(2) A clear organization is a cornerstone of a functioning team.  It is a structure.  The juice is collaboration itself.  Hence, you have to nurture collaboration.  Actively involve the team to define the various roles and responsibilities, collaboration rules, align expectations, share motivations and drivers.  Give each team member to chance to buy in his or her own role as well as all the other roles in the team.  This defines accountability of the individual and the group.

(3) Promote performance on the individual and team level.  Creating the right environment for performance is great.  At the end of the day you and your team have to perform and deliver.

(4) Project environments change, as much and as often as project requirements.  Hence, cultivate reflection and learning in your team.  Don’t pretend that you can plan everything in its very detail.  You can’t.  Adapt and move ahead, keeping the project vision in mind, follow through.

(5) Last but not least, the best high-performance context for team is worthless if the team doesn’t deliver.  There is more to project success than results.  Still, results are what other people outside a project can and want to see.  Hence, ensure ongoing delivery of results.  Don’t wait until the end.  Instead, build in interim checkpoints, deliver results throughout the project.  Not only do you give the outside world a sign that you are making progress you also strengthen the morale of your team and hence the context for team performance.  This helps secure project success.

Posted in: Empowerment, Leadership, NASA PM Challenge 2011, Project Management

Leave a Comment (0) →

Dogmatic Scrum: an end to Agile?

I consider myself a proponent of agile methologies (such as Scrum) and agile project management.  I support and live Agile not because it is a fad but because I believe it is the right approach to running projects and develop products, especially when we are talking about developoing software.  The good news that more and more companies realize the immense value Agile brings to the table.  This is not limited to smaller projects in IT.  Whole companies such as Amazon, Google or Zappos embrace the philosophy of agile.  Such companies stress the importance of delighting customers, adding value first.  Consequently the output, i.e., money, is much better than in traditional management models.

Having introduced Agile methodologies to a number of companies such as TuneUp software my experience is that Agile works.  Or, shall I say, can work.  For you have to be aware of some pitfalls the introduction of Agile brings.  To start with, you have to understand the project and company environment.  How did it manage projects in the past? How open are people to new approaches?  How fast do requirements change? – And, how dogmatic are people about their past (and present) methodologies and beliefs?
This last question goes in both directions.  Namely, it is easy to pinpoint those who we call traditionalist, waterfall proponents.  But we should also ask us, how dogmatic are we about Agile?  If you force Agile into an organization without preparing the soil, you are likely to fail.  Not because your methodology is flawed, but because of your own flawed myopic mindset.  Agile calls for an open attitude to new and changing environments.  This is the counterpart of any dogmatic belief structure.  Hence, I have always been very skeptical of those folks who believe, for example, that Scrum can be introduced and practiced only in a certain way, i.e., by following the pure textbook.  It may work in some settings.  In environments where people, especially managers, are skeptical about anything new and resistant to change, we have to be flexible.  We may have to come up with ways to gradually introduce agile elements, avoid the typical Scrum terminology, use established planning techniques (at least for some time) rather than throwing all former templates and methodologies overboard.  It is a matter of respect and professional maturity.  Watch, listen and learn before you come up with a solution.  And best, help the customer find it.  Don’t talk about theortical constructs, show how Agile works in real life, involve the customer and let the customer realize the immense potential value Agile brings with it.

There are endless blogs about the right use of Agile.  A recent discussion on Mike Cottmeyer’s blog post “Why is Agile hard to sell?”  is especially worth mentioning.

Posted in: Agile, Project Management

Leave a Comment (5) →

The “Top 3” of status reports

As managers or project managers we regularly prepare so-called status reports.  It is supposed to be a summary of the events, accomplishments, issues and upcoming milestones.  In my experience in project management I have seen numerous formats of status reports.  In many, too many cases I am overwhelmed by the amount of information presented in such reports; often the formats make you wonder how much time the preparer has.  This is not the space to list the shortcomings of such reports.  Instead I want to outline what a good and comprehensive report should entail.

It starts with an executive summary of the report.  I am not talking about a novel.  An executive summary is short and to the point.  In 1-2 sentences you summarized the main accomplishments, issues and upcoming milestones.  Sounds easy?  Well, it isn’t.  As a matter of fact I have found that it is easier to describe a situation in paragraphs rather than say 1 or 2 sentences.  The limited space you have forces you to prioritize the many issues you are dealing with.  The question which should guide you is this:  what are my top 3 issues I am dealing with?  It is likely that you are dealing with more than “just” 3 issues.  Still, you should always be able to pinpoint the most pressing challenges.  They require your first and utmost attention.  Other issues are important, too, but how much time and resources do you have to address them.  Unless you have limitless time you have to set priorities.  Acknowledging this you have to be in the position to identify the 3 most important issues and focus on solving them first.  This does not mean that you neglect the others.  You don’t; but you start with your top 3.

On this token, the rest of the status report is almost self explaining.  List the 3 most important accomplishments (or met milestones), the top 3 upcoming milestones or deliverables.  Then you move on to the top 3 issues and risks.  Alas, it is not sufficient to list the top 3 issues and risks.  Briefly describe the impact of the issues and risks, outline how you plan to resolve or control them, who is driving this solution (i.e., who is accountable for the issue and solution) and by which date you expect a solution or at least a new update.

A word on lengths and formats.  Expectations differ, no doubt.  In my own experience I have found that a 1-page long dashboard is more than sufficient.  On 1 page it should give you a mutual, exhaustive, comprehensive and exclusive overview of what is happening in your project or organization. This can be done in Powerpoint, Word or Excel format.  And maybe you even have the luxury of using a more elaborat collaboration tool.  Regardless keep it simple and on the point.  It may actually take more time to prepare a 1-page dashboard than a 2-5 pages status report.  But chances that your 1-page dashboard is actually read and acknowledged by your sponsor our your management is greater than the longer version.

Have a look at this sample report and feel free to use it.

Posted in: Project Management, Tools

Leave a Comment (0) →

Photo impressions from Conference in Athens

Yesterday I received photos from last week’s project management conference in Athens.

A project management conference and I am talking about mountains?  True.  The reason is simple: I am comparing a project to a mountain tour where the mission of the team is to reach the summit and return home safely.  In this analogy project success is not limited to reaching the summit or returning home safely.  Project success is not limited to results or milestones.  What matters too is the process to the deliveries, the journey, the experience.

For, if final results are all that matter this may as well justify death march projects where team members work long hours, where team morale is low, where team members were so glad when the project was over because it was a miserable time and they would never come back.  Unfortunately, in a lot of businesses project results are the only thing that matters.  People don’t matter.  Well, this is not my philosophy for I believe it is a dead end street.

Successful project management and leadership is holistic and accounts for the human needs as they relate to the project needs.  It helps create the right context and environment for high-perfomring teams.

Using the analogy of the mountain tour, the effective project manager and project leaders is the experienced mountain guide who takes the whole team as one unit to the summit and return it home safely AND helps create the right atmosphere and environment for a performing team to evolve.  Who do you want to be?

Posted in: Keynotes, Leadership, Project Management

Leave a Comment (0) →

Ignore your environment – or how to set up your project for failure

We all know that we live in an interdependent world.  This is common sense.  And yet again the proverb that common sense is not common practice holds true.  Recently I observed a project which was headed by an expert in his field.  He knew the business inside out, nurtured a strong network in the industry.  It was no big surprise that he was asked to lead the technical division of a new service offering of the company.  Alas, as much as he knew about the new product and services, he lacked a common project management understanding.  He was so convinced of his own expertise that he willingly ignored the project environment.  He defined his agenda and followed it.  He didn’t bother asking other people for their opinion.  This time he had the chance to prove the world that not only did he understand the business part of the service he also want to show that he knew the technical aspects and how to set up a highly efficient and yet effective technical infrastructure in record time.

There was nothing wrong with this motivation.  As a matter of fact following a vision is a noble thing.  IFF it is shared by others.  Even more important, IFF the vision is built by those who are involved.  Unfortunately this was not the case. The project manager did not share his vision openly, he withheld information from others, dictated his immediate “team” members what to do and micromanaged every step.

The project progressed according to plan.  At least this what his belief and perception were.  Until the first delivery to a sub-team which had to specify and implement “his” solution.  The feedback of this sub-team gave about the concepts submitted to them was devestating.  Little if anything was deemed valuable for implementation.  It was a mess.  It became apparent that the scope was far from being defined, even less approved and shared by all stakeholders.  The project came to a point where it was up to management to decide whether to go ahead nevertheless and fail or to step back for a second and think how to clean up the mess.

The good news was that the latter was the case.  The sub-team invited the project team to walk through every scope item of the project phase, estimated the effort and planned accordingly.  Project work could start anew. Only this time it was based on a common agreed upon scope and project plan.  The first release of the new service was delivered on time.  Alas, it was far from the originally thought scope of the project manager.

There were quite a few things the project manager did wrong.  As mentioned at the outset of this post, interdependence is not a mere buzz word.  It is reality.  You are foolish if you ignore it.  In the case descriped the project manager and the whole project would have faired much better if the project manager would have spent his energy on building a common vision, sharing information and winning the necessary support for his ideas.  Instead, he saved his energy for his own agenda, got lost in political power struggles he set up and in the process set up the project for failure.

Interdependence is all around us.  Open your eyes, identify your playing field and players and involve them.  For the better of the project.  For this what a good project manager does – care for his project and team members and not follow his own agenda.

Posted in: Project failure, Project Management

Leave a Comment (0) →

“A Fool with a Tool is Still a Fool” – Presentation

The presentation (PPT-file) is now available online at http://congresses.pmi.org/NorthAmerica2010/documents/PMT10-ppt.pdf. Feedback is highly welcome!

If you are attending the PMI Global Congress in DC next week, please stop by.  Reading a ppt-file is still different from attending an actual session.  Besides some slides will be different from those available online at this time.  Yet another reason to attend.

Looking forward to seeing and talking with you in DC.

Posted in: Keynotes, PMI Congress, Project Management

Leave a Comment (0) →
Page 5 of 8 «...34567...»