Blog Post Image

What Can You Learn About Project Management From Twitter?

Paul Naybour Paul Naybour

Published: 3rd December 2010

This is a live blog post that will be updated over the next few days as we explore what you can learn by following the Project Managers on Twitter hash tag #PMOT.

But First What is #PMOT?

Users of Twitter use the hash tag #PMOT (or label) to indicate post which may be of interest to a group of people who follow this group. The easiest way for following this group is to use some software like Tweetdeck. This way you can set up a search for #PMOT and every time a new post is made using this hash tag then is will be displayed by Tweetdeck.

So let’s get started and see what is going on today.

Book Review: “The Project Manager’s Guide to Making Successful Decisions”

The first popular post review of a new book by Robert A. Powell, Dennis M. Buede called The Project Manager’s Guide to Making Successful Decisions posted at how to manage a camel by Heather Buckley. Heather says

It’s a really in-depth analysis of decision making and the way it relates to project management, whilst providing a variety of techniques to facilitate the decision-making process. The book goes through the processes of how to frame the decision, gather information, close the decision, get approval within the organisation, and start implementing.

This sound like a really practical book; which avoids many of the pitfalls of formal decision theory. These formal approaches can be difficult to apply in practice.

Five tips from inside the Devil’s Triangle

The next post the catch my eye was by Michael Krigsman. What a cool title. He says

Still, most technology deployments involve three dominant parties: the enterprise customer, technology vendor, and system integrator. Therefore, when analyzing IT implementation projects, it is helpful to examine relationships among this triad, which I call the Devil’s Triangle

He gives five key tips for successful ERP projects including:

  1. Define the project completely by understanding what must and must not be done.
  2. Select the vendor with care he recommends making sure you get good consultants as advisors to “facilitate the dialog among client, integrators, and vendors and make sure the proposed solution fits the company’s needs.”
  3. Choice the integrator with great care. He recommends interviewing the senior staff and go over the resumes of the participants. I would also ask to interview the people who are actually going to do the work.
  4. Assemble a strong cross functional team to oversee the work including the relevant Directors.
  5. Actively manage the project with sufficient attention to the detail.
  6. Understand fully the impact of the project on the business he quotes Pam Daniels, who heads up Stylus Group, an organizational development consultancy. “Change management is a fundamental practice that must accompany ERP projects from the very start and all the way to through to the end. It continues even after the consultants have left the premises,” she says. If change management is neglected, employees may resist the new software or use it minimally. Either way, the benefits of the project are undercut even if it is a technical success.
  7. Don’t short change the training as we have all seen in many IT projects. I would also add make sure the application is fully debugged and all performance issues have been sorted before the training starts. Software with faults and poor performance will soon get a bad reputation in an organisation.

These are fantastic tips and I don’t think that they only apply to ERP projects. The same advice applied to new product development, marketing, retail, construction….

3 Planning Stages in Agile

 

The next interesting post a review of a white paper about planning in Agile Project by Allan Kelly on the web site Agile Scout. Agile project are often criticised for lack of planning. In his white paper Alan says

..if anything there is more planning in Agile than in traditional approaches, but the planning is different. It occurs not once at the start of a project but continually through the life of an Agile team.

Also he sees planning a team exercise, not the sole preserve of the project manager. He identifies tree planning horizons. A short term iteration or sprint plan which receives the most attention on Agile and has a time frame of about two weeks. Release plans which is targeting the next software release and longer term roadmaps which may last for years showing how the product may develop over the years to come.

There are lesson here for the mangers of more traditional projects. Combining flexibility with a clear sense of direction is key the success of many projects. Maybe we should ban planning software and see what changes.

Functional Managers Acting as Scrum Masters: Not a Good Idea

 

The next post from Johanna Rothman at The Project Management Hut said that in many organisation adopting Agile techniques are dispensing of the role of project manager and the function manager is leading the team by becoming the Scrum Master. Johanna thinks this is a mistake because…

The Scrum Master is not a management position. The Scrum Master protects the team’s process and removes the team’s obstacles. For me, the Scrum Master is analogous to the project manager. (I’ve never believed in command-and-control Project Managers.)

For reference the wikipedia defines a ScrumMaster as

Scrum is facilitated by a ScrumMaster, also written as Scrum Master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended

The Scrum process is an adaptive approach to project planning and execution with a strong team focus, with a focus on a spring to a new product release over a period of weeks. Johanna believes that a ScrumMaster cannot be the functional manager because

  1. The ScrumMaster needs to be part of the team, where as functional managers to some extent represent the authority of the organisation.
  2. People will be reluctant to take risk in-front of their manager (I think this depends on the culture of the organisation some live for risk taking)
  3. Functional managers (should) work at a strategic direction and not a weekly tactics.

Critical to the successful implementation of agile approaches is the use of the self organising team. The functional manager filling the role of Scrum Mater is contrary to this objective.

I agree with Johanna that it is difficult for the functional manager to play two roles, but in many project organisation the project manager and functional manager are combined, so it depends on the culture of the organisation.

This raised an interesting question “What is the difference between a Project Manager and a Scrum Master?” are they the same just using different tools, complementary or in competition. So I thought I would ask the APM Community and #PMOT

To be continued…

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.