7 Measures of Project Success


How do you define a successful project? Primarily a project needs to deliver on few basic parameters such as  

  1. Product of Project – This may be a new service, a product or a repeatable process that sponsoring organization intends to use for strategic, operational or business advantage. The customer must be able to use or validate it at project completion.
  2. Cost or Investment: Budget allocated for project should not exceed without changes to baseline scope. This is one of the primary concerns for the stakeholder along with timelines and quality in order to derive reasonable value from investment.
  3. Schedule: Project timelines are met for key deliverables so project’s product is relevant for the intent it is commissioned. This is especially true in the technology domain where go to market time can make or break company’s fortunes.
  4. Project Scope: Has project maintained the agreed scope of work and identified deliverables on time and at desired levels of utility? If there are either missed requirements or “gold plating with increased costs or time, in both cases it points to an element of failure.
  5. Reporting Metrics: Is there an agreement on measurement metrics to identify and report on key milestones and deliverables while project is in flight? If key parameters aren’t defined, it is practically impossible to measure the progress made or how much more time or budget will need to complete the remaining scope.
  6. Stakeholder Expectations: This is a tough one, especially that various involved parties have differing stakes in the project. It is important that your key stakeholder’s perceive the project outcome to be inline with their expectations.
  7. Transition to Operation: Very little thought and planning time is given on the sustainment aspects of a project delivery. It is critical that sufficient time and resources are engaged for ensuring there is smooth hand off & required transfer of knowledge between project & supporting teams at project completion & acceptance in to ongoing operations.

To conclude, your stakeholders will decide whether project was well-managed. Someone (perhaps your sponsor) will decide whether or not the project was a success. Some of the above measures may form the basis of this success. So to help stakeholders understand and decide get project success measures documented and agreed to from the start!

ProZen Global, Calgary
Project Staffing & Consulting Services
Access more resources at www.prozenglobal.com

Advertisements

Project and Program Management differences


Project Management and Management of Programs is different in multiple ways. Some of these difference are described in below table. This is just a short list and in no way intended to be a comprehensive set.

 Parameter Program Management Project Management
Organization Semi-permanent in nature, resourced to address the full range of business requirements associated with achievement of a strategic business objective. Resource requirements may be programmatic in nature and applied to all or major sets of projects undertaken to deliver the program Transient organization in nature, resourced to address a limited set of requirements that may be more temporal in nature and not recurring through all project phases. Output oriented vs. outcome oriented
Organizational Alignment Analogous to building a new company with a sharply defined strategic business objective. When existing owner organizations are adopting program management for the first time, organizational change management processes are an early activity to assure that owner elements understand their changed role in a program delivery approach Team alignment around project and contract requirements. In joint venture or prime-sub project structures this alignment may include “cultural” alignment as well as team building activities
Outcome Definition Strategic Business Outcome (enterprise viewpoint) Defined scope, schedule and budget (output viewpoint)
Risk Management Management of all risks associated with achievement of the defined strategic business objectives Management of assumed risks
Requirements Establish programmatic and system technical requirements and allocate as appropriate to individual projects Manage project to meet the allocated programmatic and system technical requirements
Interface Management Management of all programmatic interfaces between defined projects as well as other programmatic interfaces with stakeholder groups Management of allocated interfaces, if any, and all interfaces within the assembled project team
Execution Planning Program wide execution planning including top level schedule, budget, performance standards, supply chain configuration and contracting strategy Project execution planning consistent with agreed to scope schedule, budget. and performance standards
Sequencing Sequencing of programmatic activities including defined projects; re-sequencing of projects and other programmatic activities as required to achieve the desired strategic business outcome Sequencing of project activities to achieve project execution requirements within any programmatic constraints imposed by contract
Timeframe Through achievement of strategic business objectives (more permanent in nature) Duration associated with completion of project activities
Stakeholder Engagement Identification and integration of stakeholders’ interests and proactive engagement to assure achievement of strategic business objectives Interaction with stakeholder groups only as contractually provided for

Comments are welcome to share other differences you find in Project and Management as per your experience!

Shyam Verma, PMP, ITIL
IT Project & Program Delivery Professional
LinkedIn:spverma. Twitter: Shammy11



Resolving project team disputes effectively


We all know how frequently a small disagreement within the team members can  flash-over into a full conflagration in no time, scorching you and your colleagues in minutes. What it means is that you as the leader of the project team need to think on your feet and take a quick decision to douse the flames before they have any significant negative effects on the team and project outcome.

Conflict resolution does have some trusted and tested techniques that can be used as per the specific situation.  These techniques are listed as below;

  • Confronting: A resolution technique that involves face to face dialog and focuses on win-win outcome
  • Compromising: This is where stakes are small and both parties looking for a quick resolution
  • Smoothing: One party loses or obliges for the sake of achieving the overall larger goal or for future trade off
  • Avoiding: Temporary solution to postpone issue for future. Leads to recurrence of the issue
  • Forcing: Win lose situation where one party wins at the expense of other party; rarely brings a lasting solution

The best answer is to have a conflict resolution mechanism set ahead of time – for example ground rules for the project team. This is something that team already has in place and agrees to abide by and has a buy in from all affected members.

The reason this is the best alternative to choose because trying to resolve a conflict when tempers are high may lead to distrust from one of the parties.  While if you have ground rules laid out well in advance, there is no way it could be ignored by any party privy to the conflict. What has to be done is ascertain the facts and view it from the perspective of the rules already in place! Team norms should ideally be established when the unit is first formed. These are rules that help the group run effective meetings and make sure everyone is heard. Some examples of team norms:

  • Meetings will begin promptly when scheduled.
  • One person talks at a time; there are no side discussions
  • De-personalize discussion of issues – no attacks on people
  • E-mail and other communications will be answered within 24 hours.
  • In event of a disagreement, a final decision would be made by the PM/GM
  • When we pose an issue or a problem, we will also try to present a solution.
  • No responsibilities will be assigned unless the person be assigned the responsibility accepts it

Do you have your ground rules set up for your project team?

Shyam VermaPMP, ITIL

IT Project & Program Delivery Professional
LinkedIn:spverma. Twitter: Shammy11
This article is also available on blog site http://pmpower.wordpress.com

Evolving role of Enterprise PMO


In recent years, with general adoption of IT Governance practices, Enterprise Project Management has become more critical than ever before as it is widely recognized that a project co-exists with many other projects in the enterprise, or are part of one or more programs. While the initial mandate for PMOs was to only plan and track the existing set of projects and aimed for helping project professionals, envisaged more in the lines of functional department. However, given the strategic value of PMOs in today’s fast paced enterprises, they are not necessarily limited by that original stereotype.

So in that sense, PMOs today no longer exist as isolated function that directed only to the project managers and generated project reports periodically. Even though it is still the owner of setting the organization’s Project management methodology and prioritizes future and current projects against strategic business goals. The later has equally become more important given the pace of development and time to market pressures thereby area of more sought after value

The evolution: Over the years PMO functions have become significantly broad-based from just being the body of knowledge, training and reporting but also leading delivery accountability on critical initiatives. It has assumed and rightly being leveraged by several execution centric organizations as an integral part of delivery arm or business unit. Some time structurally organized horizontally and collaborating with several business verticals and corporate functions that are engaged in delivery of critical project and programs. In that role, it can and in some enterprises already performing the role of ‘delivery assurance’ continuously setting baselines and metrics of delivery efficiency as well as providing that crucial insight in to longer term strategic planning.

The Integrator: With its continuously evolving role, today it is much more aligned with not only with technical functions (R&D and technology Labs) within the organization but also business, HR and legal functions playing much-needed ‘integrator’ role with the bigger picture mandate. Based on the knowledge of past projects, baseline technical standards & over time potential improvements, it also provides the planning confidence to set the bar right for what is feasible against what is not for execution stage.

Value for top management: PMOs provide CIOs the structure needed to both standardize project management practices and methodologies for repeatable project processes as well as business value in identifying best suited program initiatives for implementation and funding viability for achieving organizations strategic intent. . Clearly today PMOs are more strategically valuable for business leaders and senior managers including the C level executives as much as it is with project professionals in day-to-day role as it advises and champions the business initiatives with best ROI on investment for the company.

Shyam VermaPMP, ITIL

IT Project & Program Delivery Professional
LinkedIn:spverma. Twitter: Shammy11
This article is also available on blog site http://pmpower.wordpress.com

Costing traps in IT Projects


One of the major challenges with large and complex projects (spanning several industries) is cost overruns from original budget making the initiative too expensive to be worth eventually. A noteworthy example is recently concluded Common Wealth Games held in New Delhi where the budget overran by large magnitude. While whole of that overrun may not have been due to pure project management but also governance issues but such events do compromise the position of lead Project manager and credibility of project management discipline overall. To avoid cost overruns one has to be very careful with planning of the project resources, defined deliverables and constraints from the beginning. Let’s take a common example as to what can go wrong!

So you have landed a project that has a defined and well documented scope and deliverables. You also have the required authority and power to manage the resources required to deliver the product of the project. Before you start using the resources you may want to double check who are these resources are and how much they would cost the project to deliver. This is especially true in case you are dependent on any external resource or consultant to bring in that much needed expertise your internal resources do not have. The trap essentially is the hidden costs that do not seem quite obvious in the beginning.

Let’s say you need an architect to design the database of your new application and internally either you do not have resources with relevant expertise or these resources are not available to your project. In your budget, you may have considered X Hours for this activity at the @ of Y dollars. However when this consultant arrives to start work on the database, you may realize that he needs a laptop to work on with all required software fully loaded!

Did you consider the lodging and boarding expense if applicable along with software license cost in your budget? How long will it take to get these required software and laptop to arrange? Will this consultant have any other productive project activities to do in the meantime or will those hours be a strain on your pocket? Are there any other tasks that might be impacted due to delay in database creation costing you additional dollars? It may not be possible to fully estimate all the unforeseen expenses but with some careful advance planning you can minimize the damage or have cheaper alternates in place!

Shyam Verma, PMP, ITIL
Program & portfolio mgnt professional
LinkedIn:spverma. Twitter: Shammy11

Calculating FTE Hours


Full-time equivalent (FTE) is a way to measure a worker’s involvement in a project. An FTE of 1.0 means that the person is equivalent to a full-time worker. Although the accepted HR  term for the “E” in FTE is “equivalent”, in colloquial usage or in project management terminology it is referred as full-time employee! FTE hours, can be used to measure whether an employee or resource is full-time, or how many students at an educational institution are full-time.

To better understand this:

  • Start with 40 hours a week

Use 40 hours a week as your default for full-time employment when calculating FTE hours for a project. Some projects may measure full-time status differently, such as 35 or 37.5 hours a week instead of 40, so be sure to adjust according to your project’s requirements.

  •   Figure out the number of hours in a pay period

Figure out the number of hours in a pay period by multiplying the length of the pay period by 40 hours a week. For example, if your pay period is 2 weeks, your total number of hours in a pay period would be 80.

  • Divide hours worked by hours in a pay period

Divide the number of hours your employee worked in a pay period by the total number of hours in that pay period. The total equals your FTE hours. If an employee worked 40 hours out of 80 hours in a pay period, your total would be 0.5 FTE. It’s that simple!

Shyam Verma, PMP, ITIL
Program & portfolio Mgnt professional
LinkedIn:spverma. Twitter: Shammy11

Managing Project Scope Effectively


For most projects, keeping the project schedule and cost in control pose the biggest challenge and stake holder expectation after the level of quality. A tight definition and active management of project scope can not only deliver instant results but also relive you of unnecessary squeeze on your project resources. Here are some ideas that can put you back in track or give you some directions on your next high profile project!

  • Scope statement: at times the scope of your project is not very clearly defined from the beginning or is under defined to say the least. Please remember the scope statement that was prepared at the time of Pre-Sales stages or before the actual analysis phase may not be sufficient or complete. So spend some time verifying the fact if some additional things made their way or something that was cut to meet timeline or budget constraint. It is a good practice to serialize key business requirements for estimation of time and cost. Also remember the initial scope statement is only for an interim period until the scope definition is completed as part of planning phase.
  • Objectivity of outcome: compare the statement “Improve service by providing an information system to respond to customer inquiries.” With “Able to answer customer queries last 2 monthly statements and last 60 days transaction over the phone.” Clearly focusing on the outcome brings more clarity and saves lot of vagueness and future disputes with your customer over actual intent. It is recommended that scope definition or project charter is developed in iteration essentially with customer involvement using an authorized document format.
  • Managing Scope Creep: This is a common problem where requirements are not clear and complete. Essentially this is due to incorrect interpretation of the requirements or due to requirement gaps in the scope definition. Sometime additional requirements come up after more clarity emerges or there are changes in stakeholder expectations due to changes in external environments. Therefore it is essential that your project plan has provision to incorporate and approve new requirements and modifications in existing one after careful consideration of impacts by project CCB (change control board) or governance board
  • Project deliverables: An internal deliverable is something that project produces as part of the project for internal use e.g. E-R diagram while an external deliverable is something that project team provides to the business users. I have seen some PMOs require that assigned PMs define internal and external deliverables (with agreed templates) and track at least phase by phase to ensure timely delivery and sign off with customer. This is a good practice and provides a level of comfort and confidence to the stakeholders as well.
  • Functional specifications: Scope definitions could be done using multiple techniques. This could also help in closing missed gaps. One of the techniques is to capture major functionalities by using decomposition. This could be done at the same time with data definition if possible. However if that is not practical the functional specification could provide the required data requirement.
  • Specify Assumptions: Each project initiatives have some or the other dependencies represented by assumptions. It is recommended that each of these assumptions are documented at relevant deliverables and followed up at the earliest. As the false assumptions could pose potential challenges to the project plans in terms of schedule milestones, resources, quality and cost constraints.

While most project managers focus too much on these two constraints however the biggest issue that results in to time as well as cost overrun is not able to manage scope of the defined project. Therefore, a tight definition and active management of project scope can not only deliver instant results but also relive you of unnecessary squeeze on your project resources.

Shyam Verma, PMP, ITIL
Program & portfolio Mgnt professional
LinkedIn:spverma. Twitter: Shammy1