How Do You Define ‘Project Success’?

20 February, 2013 by Tim in Project Management Plan, Uncategorized | Leave a comment

Measure Project Success

From a PM’s perspective my view of project success is the same as my customer’s (project sponsor). It makes little sense for me as a PM to have any different view. And the PMBOK 5th Edition while adding a small definition of ‘Project Success’ (2.2.3) does not stray from what it has said in the past regarding project success.

Under section 4.1.3.1 PMBOK clearly states (and I whole hardly agree):
5th Ed. Pg. 72 – “Project approval requirements (i.e., what constitutes project success, who decides the project is successful, and who signs off on the project),”

What the PMBOK does say is that the project should be measured in terms of scope, time, cost, quality, resources, and risks. While these are logical areas from which to derive project success criteria from they are by no means the only areas. Some organizations might include unique project factors such as end-user acceptance of new computer system or success of a product in the market place.

PMBOK – Project Success

Regarding success and the last baselines as noted in the lastest PMBOK (Sec. 2.2.3, Pg. 35), I really do not have an issue with this especially in projects where the initial scope is ill-defined or has changed radically over the course of the project.

Neither do I have an issue with the responsibility of the sponsor as the primary promoter (Sec. 2.2.1 Pg. 32) of the project and the one responsibility for the organizational value of the project. I find it curious when a PM finds a need to explain the value and worth of a project to the project sponsor. But I will preface this by saying my experience is limited to IT PM in several industries and not for instance (building or other industrial) construction.

Read More

Remote Project Management

1 February, 2013 by Tim in Project Management Plan | Leave a comment

Remote management of project teams is not only possible but it is fast becoming a norm for multi-national organizations in this digitalized world. For the past five to six years I have successfully managed technology projects with globally dispersed team for various clients with team members in many different time zones and with multiple cultures to accommodate. Mindset and effective use of technology is the key to successful management of these projects. With these types of projects the PM is the proverbial center piece who needs to make time to individually understand the needs, both on a cultural and technology basis, for each team member. While requirements and scope are key to any successful project these become critical with global teams especially when team members are not dedicated to a single project.

For remote project management to work the PM needs to draw out silent team members. How this is accomplished will vary depending on the team dynamics. As a US Midwesterner with a deep baritone voice I seem to have an accent that is not easily understood by all team members. Hence I will use both voice and text during meetings. Critical issues need to be in writing before discussions so all can have a chance to discuss locally and understand the facts before discussion with the entire team. In the sense of what a communications plan is for – that is determine communications methods/frequency for the project’s various stakeholders I would say no it is not. What are key are communications channels and methodology tailored to the various project teams member’s needs. This does not say the communication plan is not important but how communication is facilitated especially in live meetings is critical.

A few key points I always cover:

  • Communication plan must lend itself to the needs of the remote team members.  Especially in regards to time of day.  Some regular meetings might be rotated depending on the team’s preference.  Above all else holding regular calls is critical to keep all team members synced with project progress and issues.
  • Communication medium / methods need to be reviewed and adjusted to accommodate all members.  This will include but is not limited to voice, live document sharing, central document storage, and chat rooms, live video, formal and ad-hoc reports.  The project base language must also be considered but from my experience when accommodating three plus languages, English will be the standard.
  • Project schedule deliverables takes more thought if the team is working around the world and sub-teams are dependent on other sub-teams.  For instance having a team in India idle on a Tuesday because they are waiting for a predecessor from a sub-team in San Francisco scheduled to deliver on a Monday is not good for project efficiency.
  • Project calendar is critical when working with remote dispersed teams.  Understanding the availability of all team members and utilizing member specific calendars is critical for task scheduling.
Read More