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

Scope definition through User stories


User stories

The benefits of achieving a working software in less money, better risk mitigation mechanism (because you test early and test often) and dependence on process not individuals is one of the key reasons that XP has become one of the most preferred software development methodologies in recent years. Agile practitioners term User stories to be “Technique of expressing requirements as user stories to be an effective approach on all time constrained projects and are a great way to begin introducing a bit of agility to your projects & requirement management approach.”

If you happen to be one of those PMs who need to deliver your project in such fashion chances are you are most likely to use your scope statement e.g. project requirements in terms of user stories rather in standard functional requirement document. Hence it would be invaluable to know how you can employ user stories to define and plan project scope.

What are user stories?

A user story describes what functionality is required from the perspective of business users in simple or plain English running through different steps or stages to accomplish desired functionality. In simple terms, a user story provides the clear understanding of who wants the functionality, how it would work and why this functionality is required. In most cases user stories are written by customer or a customer representative working with a developer where developer may ask some questions to clarify the user actions but does not influence the idea creation process. User stories are used mostly in agile software development methodologies to provide the basis of features required in the software.

Development Process: While business user or customer narrates the scenario, developer makes notes on a 3×5 inch Card with functionality or requirement name, user action description, test condition, rough estimate and any other relevant point. For example, ” As a business user I want to be able to search for my customers by their first and last name,” or the “Application starts by bringing up the last document user was working with.”

The 3 basic tools used in the process are namely, Card as mentioned above, details around Conversation where details are noted as discussion with business user happens and thirdly Confirmation or Conditions that must be met for for the basis of user acceptance.

In case there is any ambiguity on the user story or it is deemed complex or too big the process of refinement is repeated until the story is concise and agreed by both user and developer. Please note the user story is not supposed to be definite business functionality and changes to the functionality are accepted at the time of development or even testing. From that perspective the process represents one of the key features of Agile development.

Advantages: User stories are a quick way of eliciting customer requirements without having to spend too much effort on formalized requirement documentation and bypassing overloaded administrative tasks for maintaining them. The purpose of user story is to respond promptly with less overhead in rapidly changing real-world requirements

Limitation: since the User stories are informal way to elicit requirement the test scenario for acceptance purposes should be in place without which the implementation of the requirement do not have customer acceptance.

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

There are three basic tools used in the process namely Card as mentioned above. Secondly details around Conversations where details are noted as discussion with business user happens and thirdly Confirmation or conditions that must be met for acceptance.

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