Project Vs Program Management

project management

Project Management and Management of Programs are different in multiple ways. Some of these difference are distinctive while some other may not be so clear at first glance. Below are few of the most common differences that they represent.

 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.

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



 

Why You Should Delegate More

Why You Should Delegate More

Work delegation is an art that can be a win-win for both a leader and subordinates. Still rarely you find leaders and managers do it right way. There are two extremes we often see in the workplace. A control freak, who is obsessed to do everything by himself, It might be a reflection of either a job insecurity or a false obsession with perfection or doing everything his or her own way. Both these approaches are killers (literally) and does not produce effective or efficient outcome.

  • What to Delegate:

Delegation is a fine line where one has to decide what need to be delegated and what needs to be kept. There is a clear choice between mundane or routine tasks which are not important but have to be done. These types of tasks are easier to delegate (down) as they can be done by a junior staff with acceptable or desired level of quality. At times this may involve some on the job training.

Contrary to this, there are some highly technical or complex tasks which require higher level of expertise or domain experience. For example, presentation of project report to steering committee or Proposal for an upcoming project. Delegation of these type of tasks are not easier and can’t be delegated to someone who is either not qualified so lacking the ‘expertise’ and at times may require delegating (Up) someone superior or with experience.

Most leaders do not think delegating these tasks because these tasks are also something that reflects their key skills or so to speak USP and delegating these tasks may actually make manager’s position replaceable!

  • How To Delegate:

There are simple steps to ensure the delegated task get done to desired level of success and you don’t end up spending more time supervising.

  • Select the task and Find a resource with suitable skills
  • Provide sufficient work instructions & measurable goals
  • Focus on task “Objective” of the task not procedures
  • Supervise, Review periodically & give objective Feedback
  • Step in to help only if needed, else do not interfere.
  • Expect teething problems:

If even after your clear instructions and support you see that the task is back on your table for your action, the delegation clearly did not work. Many managers find themselves in this position often and don’t know what to do next. Some even accept the fact that their team is not up to the mark for the responsibility. Let’s explore the possible reasons;

  • First, in some cases, the subordinates who have been delegated the tasks bounce the task back to the manager because they don’t want to take the risk or be blamed for the failure.
  • Second, it may also be possible that manager and the subordinate do not have the same understanding of the tasks to be performed and the empowerment going with that. Clarify the expectations and ask for his / her next action plan. Support with your inputs but do not micro manage or step in when not required.

It is important that imminent challenges are discussed and worked through before abandoning the idea. This is because if delegation fails, both parties loose. Subordinate doesn’t see any room to grow and you as boss feels stuck with routine and mundane work load & not finding time for critical and strategic work.

At last you should also be open to let it go if things don’t work out despite genuinely putting efforts by both ends. Also for few people (e.g. Perfectionists!) this is always going to be tough!

 

ProZen Global, Calgary

Project Management & Consulting Services

Access more resources atwww.prozenglobal.com

Project Prioritization using Bubble Chart

 Bubble Charts

Bubble Charts

What are Bubble charts: Project prioritization is a crucial activity in portfolio / PMO Management for managing project demand pipeline. Projects triage or prioritization process takes in to account strategic fit, business impact or opportunity, cost benefit analysis (ROI) and level of risks involved to rank all the projects in demand pipeline for EPMO review and decision. This project ranking allows assignment of score or weightage on a scale of 1-10. Bubble matrix charts are used to present this integrated view in easy to understand visual format.

Process and Tools: The processes and methods used by performing organizations vary but in general the review standard is defined and documented and governed by the enterprise PMO or departmental portfolio leader. In large organizations, this activity is performed using a demand management or PPM tool for the purpose of ease and accuracy given large number of project intakes. However the same results can be achieved using spreadsheets with few macros by smaller or still evolving EPMOs that do not have access to sophisticated demand management or PPM tool sets.

Advantages: Project prioritization bubble charts provide a number of advantages over traditional spreadsheet listings. The bubble charts are especially useful for business stakeholders and senior executives to support decision on which of these projects align to the stated company strategy and should be implemented. Few of these advantages are;

  • They are easier to present status and findings
  • They are visual and can also be color coded
  • They are simple to use and make updates
  • Bubble charts provide single integrated view
  • Automatically updated if integrated in PPM tool 

ProZen Global Consulting, Calgary
Project Management & 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 Xtream Programming has become one of the most preferred software development within Agile 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 business requirement and analysis approach.”

If you happen to be one of those project managers 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, plan, and manage project scope effectively.

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.

Agile and User Story

 

 

 

 

 

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 requirement 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.

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

Who, What Why of PMO!

The below info-graphic by pmalliance pretty much sums up broadly what is Project Management Office or PMO, the broad mandate PMOs have in organizations as well as the value they can provide and who it is for or the audience it serves. Who, What Why of PMO!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ProZen Global Consulting, Calgary Project Management & Consulting Services Find more Project Management resources at www.prozenglobal.com

Seven Rs of Change Management

ITIL PROCESSESIf you are managing an information technology project or program you are likely to introduce change in some form, shape or way in to the business or technology environment as result of the initiative. You may note the very reason for initiating a project is to produce a unique product, service or result intended by the sponsoring organization.

All projects have a defined way to carry through this change using project change management which describes process of identification, analysis, review, approval, implementation as well as sustainment of the desired changes scoped in the project.

ITIL change management recommendations emphasize assessment and evaluation of the change requests presented to change Advisory Board or CAB. As part of the change assessment, some key questions, generally known as 7 Rs of change management, help judging the likely impact of the change on service assets and configurations. Therefore it is important that change requests cover details of these questions for a successful review and positive outcome of the RFC.

When raising a request for change or an RFC, consider following important questions to have a complete or near complete assessment of change proposal.

  1. Who RAISED the change?
  2. What is the REASON for the change?
  3. What is the RETURN required from the change?
  4. What are the RISKS involved in the change?
  5. What resources are REQUIRED to deliver the change?
  6. Who is RESPONSIBLE for build, test & implementation of the change?
  7. What is the RELATIONSHIP between this change and other changes?

Even though this is more of a service operations activity it can still be very useful in your project change management process simply because it allows you to analyze the potential change in its totality and possibly point to an area that may need more deliberation for suitable solution before going ahead with the change itself.

Note it is always a good practice to identify all potential changes that your project is likely to introduce and start detailing them to address above seven Rs as part of analysis and design iterations rather than to wait for the execution phase or stage. This strategy is helpful in two ways, one you have ample time to put them through various project stakeholders for review and input, second you have it included in your project plan or road-map to ensure required resources are in place for successful execution.

In addition, make sure that all your stakeholders are engaged and aware about these changes so they can extend their support or clarify about any doubts or able to put forward any suggestions ahead of the crucial implementation.

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