How Projects are different from Programs


Program management differs from project management in several fundamental ways. In the simplest of terms, program management is the definition and integration of a number of projects to cause a broader, strategic business outcome to be achieved. “Projects produce deliverables; programs output benefits so as to sustain, advance or achieve organizational objectives” according to page six of The Standard for Portfolio Management.

Program management is not just the sum of all project management activities but also includes management of the risks, opportunities and activities that occur “in the white space” between projects! Especially program  directly addresses and supports the corporate strategic goals unlike project that is more concerned with a specific outcome and deals more at the work package level. From the organization point of view too, program decision on resourcing, standards and compliance typically affect associated projects. Programs and projects have different focuses but working together, they can create the right balance and momentum needed to achieve strategic goal.

Project management and program management are distinct processes, but they often interrelate. For example, a company may initiate a major program to implement an enterprise resources planning software throughout the firm.

SP Verma, PMP, ITIL v3
IT Project & Program Delivery Professional

LinkedIn:spverma. Twitter: Shammy11
Access more resources at http://pmpower.wordpress.com

Need for PM Training & Certifications


Traditional learning model

Despite the fact that here is a lot of buzz in business about importance of project management skills in resources aligned in delivery of projects, the trend of formally trained individuals is quite small or insignificant. Few years before (when PMP or Prince2 credentials were not as sought after as today) professionals as well as organizations did not feel the need to have formal training for PM professionals. Rather it was more likely that these resources gained ‘hands on’ knowledge and skills while performing the jobs in their day today work life & going through company’s existing processes, procedures in use and learning from mistakes made in the live environment. It is quite obvious that many learned the tricks & techniques with historical tried and tested ‘trial & error’ method possibly unknowingly at the organization’s expense!

PM Training becoming mainstream

It is also evident that due to lack of structure and infancy of the discipline the failure rate of projects were higher that what they might be today. make no mistakes, I am not suggesting that improved success rates of projects today compared to a decade earlier is primarily or solely due to acceptance of formal training and certifications of professionals in the industry, the must have been other factors at play as well such as improved tools and better awareness and knowledge around techniques and off course increased level of maturity of the performing organization. Over the years awareness about value of formal Project Management training has been recognized by the industry and this reflected in the fact that now there are large numbers of training schools/colleges offering variety of training programs for varying levels of needs.

What drives people for credential

Even with much greater emphasis on requirement for industry recognized credentials, the key aim of individual for gaining PMP, Prince2 or similar badges is more to do for financial benefits & due to peer or organization pressure rather to really gain additional subject and process knowledge for practical application purposes. I do believe that going through the process of preparation for the certification does help in the way that individual gains basic level of subject knowledge and terminologies, which in itself has remarkable value.

Why Skill disparity still remains

What actually is used in day today practice is mostly to do with framework established by the performing organizations which depends again on the level of maturity the organization is working. So what it means is that even though 2 individuals with same level of experience and industry recognized credentials may have quite different level of expertise in Project Management knowledge area due to the exposure and practical use will defer based on the adopted practices by their organizations. Credentials & formal training in professional fields act as minimum level of knowledge/skill expected by the Industry from project management professional, this is still an excellent value, given this is what expected out of these programs.

Shyam VermaPMP, ITIL v3
IT Project & Program Delivery Professional
LinkedIn:spverma. Twitter: Shammy11
This article is also available on http://pmpower.wordpress.com  &

Stakeholder Analysis For Better Projects


Managing a successful project needs a high level of stakeholder management on an ongoing basis. So who are stakeholders? 

Stakeholder analysis is the process of identifying the individuals or groups that are likely to affect or be affected by the project outcome and sorting stakeholders according to their impact on the project and the impact the project will have on them. It is not only a critical process in the initiation phase of the project (best practice is to revisit it at least after each project phase if possible) but also sometime becomes factor for success of the project especially for the large enterprise wide programs. The output information helps in effectively managing the stakeholders by meeting their expectations and gaining their confidence.

Stakeholder analysis can entail below activities;

  • Capture and document the characteristics of key stakeholders.
  • Capture the interests of stakeholders in relation to the problems that the project is seeking to address
  • Capture conflicts of interests between stakeholders helping to manage such relationships later in the project
  • Capture relations between stakeholders that may enable “coalitions” of project sponsorship, ownership and cooperation
  • Identify the capacity of different stakeholders and stakeholder groups to participate
  • Capture and document appropriate level of participation by stakeholders e.g. inform, consult, partnership or all of these

So chances are more people your project impacts by its outcome and activities, it’s obvious that more people will also have some degree of influence over the projects direction in a positive or negative way. Some of these “impacted “will likely benefit directly or indirectly and will become supporters in your endeavors. Similarly people who are likely to impacted negatively by the project will block the project activities or act in a manner to delay. Hence it is important to ensure to cultivate more supporters and engage affected for managing their expectations to an extent possible without digressing on the project’s deliverables or products. Therefore it is essential to analyze these stakeholders from the perspective of your project. For simplicity, project stakeholders can be classified in following types.

Classification of Stakeholders

  1. Primary stakeholders: are those ultimately affected, either positively or negatively by an organization’s actions.
  2. Secondary stakeholders: are the ‘intermediaries’, that is, persons or organizations who are indirectly affected by an organization’s actions.
  3. Key stakeholders: have significant influence upon or importance within an organization (they can be part of either two groups above)

Managing Stakeholder expectations

Essentially you will need to develop a strong working relationship with key stakeholders. Primary or Key stakeholders are required to be engaged proactively time to time for consultation, key decisions, support and selling the benefits of project outcome to ensure the strategic objectives of the project or  program are achieved. This also draws on the robust communication management to keep these stakeholders engaged and abreast of current challenges, issues and any significant success through regular communication and in person interactions to meet their information needs. The communication plan may document who receives communications, when, how and to what level of detail. Protocols may be established including security and need to know parameters.

Key Benefits of Stakeholder analysis / Managing Expectations;

  • Influential stakeholders can be identified early and their input can then be used to shape the scope and deliverables
  • Cultivating support from the powerful stakeholders will help the engagement win more resource, thus making the project or program more likely to succeed.
  • The project and program management team identify conflicting or competing objectives among stakeholders early and draft plan to resolve the potential issues
  • By engaging and interacting with stakeholders early and frequently, the  team can ensure that they fully understand and are convinced of the benefits of project goals
Shyam Verma, PMP, ITIL
IT Project & Program Delivery Professional
LinkedIn:spverma. Twitter: Shammy11

Increasing Value of Project Management Office


The PMO does not necessarily  manage projects, so in many organizations the PMO does not have a direct project connection or it is indirect. Hence, the value proposition for a PMO can be less tangible and more subjective. A centralized PMO makes great sense to ensure that all project managers have a core set of project management skills, common processes and templates.

The PMO also acts as the owner of the project management approach and supports project managers to utilize common project management practices, procedures and process templates. In addition, the PMO will serve as a place for providing organizational view of the status of all projects and can report on the improvements being made to project outcome over time.

Although PMOs can be established to provide a narrow or broad set of services, this list includes many of the common responsibilities a full PMO would perform.The key value of a  project management office includes:

  •     Optimizes delivery cycle time due to better insight in to delivery processes
  •     Optimizes delivery costs by pruning to non value added activities
  •     Improves quality of project deliverables in mid to long run
  •     Early identification and proactive management of project issues and risks
  •     Fosters sound project management best practices
  •     Better containment and management of project scope & risks
  •     More opportunities to leverage and reuse historical project knowledge
  •     Improves accuracy of estimates by applying standard organization baselines
  •     Better communication with clients and stakeholders
  •     Improves perceptions of your organization by your clients
  •     Improves people and resource management ensuring optimized uses of scarce resources
  •     Reduces time to get up to speed on new projects by applying client specific tailored processes

At an industry level, a PMO is increasingly being seen as an important component required to the  success of projects, and hence, major contributor to the future success of the entire organization. At a more operational level, the value provided by a PMO is indispensable.

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

Challenges in managing global programs


  • Communication:Nearly 70% of large projects and programs fail due to poor communication. Hence it is important that you tailor your communication plan by understanding communication needs of your stakeholders in terms of
    1. Who needs what information
    2. When will they need it
    3. From who

Ensure that everyone part of the program understands their roles & responsibilities, program objectives and as some items may not be explicit. It may be possible to have different type of communication techniques for different audience e.g. sponsors & senior executives may only want executive summary with key issues and achievements in a dashboard instead of detailed report. The same thing is not true for the other stakeholders so don’t assume unless you are sure. Also know when and where to use written or verbal communication tools.

  • Language: Language is probably last frontier of international trade. More than 65% of world workforce does not speak English. Therefore it is a key challenge in most global programs. You can reduce the damage to some extent by:
    1. Using simple sentences
    2. Avoiding jargon
    3. Speaking slowly
    4. Using multiple channels
    5. Confirming understanding
    6. Seeking acknowledgements
  • Culture: In some regions business culture has significant impact on ways of life. For example in the Middle East, Islam guides most social and business behavior whereas in China, same can be said about Confucianism, Japan poses many intricacies of etiquette & protocol developed out of their uniquely hierarchical society.
  • Time zones: Though this may sound like a non-issue but pay attention here to ensure the meetings outside time zones of some teams are well notified in advance and only set to accomplish critical decisions or discussion not for routine and mundane tasks.
  • People & politics: In an outsourcing environment with multiple vendors, there are process and political challenges in knowledge transfers, hand offs and roles and responsibilities unless carefully defined in advance as older vendors had better inroads into the client’s management chain. Same can be assumed in case of an outgoing person in charge in captive IT department. Therefore it is of utmost importance to do some groundwork to have clear queries to have the information and support you need.
Shyam Verma, PMP, ITIL
Program & portfolio Mgnt professional
LinkedIn:spverma. Twitter: Shammy1

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