Beyond PMO Consulting

"welcome to my personal blog," Ammar W Mango

  • about me

    Organizational Project Management Consultant, using profession as a platform for learning beyond just work. My passion is learning more about self, people, universe, and God.
    I am into Religion, Meditation, Yoga, and Tai Chi. I love learning about human behavior and motivation.
    I am a gourmand who loves healthy food and following latest research into health and natural healing and remedies. I jog and swim whenever I get a chance.
    Please write and tell me about yourself
    Welcome to my blog

  • New!

    PMPNOW Download Link

    Download my new Mobile App PMPNOW! FREE

Posts Tagged ‘PMI’

Sustain Benefits; Organize into Programs

Posted by Ammar Mango on October 4, 2016


If a company assigns a project manager to build a new branch, is the project manager responsible if the branch does not perform well? Most likely the answer is no.  As long as he delivered the branch according to requirements like scope, time, and cost.

This is a major issue today in organizations; there is a gap between the strategic objective, the project’s product or service, and the ongoing operations based on that product. In the branch example, someone decided there was a need to expand into a new location.  The organization assumes that simply initiating a project to open  new branch is sufficient to meet the strategic objectives behind the decision.  So a project manager is assigned to “deliver” a new branch.  But once the branch is delivered, and handed over, the branch is not attracting customers.  So they start another project to correct the issues making the branch not attractive.  etc.

The problem is the sporadic effort of dealing with the initiative.  A much better approach would have been to identify the strategic objective behind the requested expansion.  Assign a program manager, to see the expansion through beyond just delivering a new branch.

So a Program Manager would be assigned to identify expected benefits from the Program, work with key stakeholders to develop a program road map, program plan, and road map.  The program will include multiple related projects that aim at achieving the benefit of expanding into a new geographical location, for example.  The Program Manager will still be responsible for the Program and delivery of benefits beyond delivering an opened branch.

A big part of Program Management is Sustainability of Benefits.  A Program Manager would be responsible for operations, marketing projects, infrastructure projects, customer loyalty sub programs, etc, and whatever else it takes to ensure achieving and sustaining the benefits.  Once the benefits sought are in place and sustainability is ensured, only then would a Program Manager close the Program.

Contrast the above to the act of initiating and closing a project.  The project is about delivering a group of deliverables.  Programs are about delivering values and benefits. According to the Project Management Institute, PMI, Programs Are a group of interrelated projects managed managed to produce benefits that cannot be achieved from managing each project separately.

Organizations who recognize the difference between programs and project will quickly reap rewards of having accountability and governance associated with benefits and value focus that a Program offers, not just a deliverable focus that a Project offers.



Posted in Uncategorized | Tagged: , , , , | Leave a Comment »

Top Ten Differences between Managing a Program versus a Project

Posted by Ammar Mango on September 4, 2016

space program

Program Management is managing multiple related projects combined to deliver benefits not achievable from managing them separately.  This makes Program Management a magnitude of complexity over Project Management.

These are the top ten differences between program and project management:

  1. Programs are about benefits, not just deliverables.  For example, a project manager delivering a system implementation is responsible for the delivering the system functional for the organization.  However, in a program setting, the program manager would probably be responsible for the strategic intent behind the system.  So, the system implementation might be part of an initiative to improve the organization’s ability to do business online.  So migrating online is a program, and the system implementation is one of many projects the program manager has to worry about to ensure delivering the benefit (do business online) .
  2. Programs require a lot of stakeholders’ expectations management, much more than what a project requires.  Remember programs have multiple projects under them and affect many more stakeholders than a project.  So managing expectations become more difficult.
  3. Programs bring about deeper and tougher changes at the organizational level than a project does.  This makes resistance to change much higher towards a program compared to a project.  The program manager must have the ability to deal with this resistance to change proactively and throughout the program lifecycle.
  4. Programs usually have a much longer span of time than projects.  In a single program many projects are initiated and closed over many years (usually).  The longer span of time adds to the complexity of the program and poses its own challenges when it comes to funding, managing stakeholders, getting buy in and commitment, etc.
  5. Programs financial management is more complex than a project.  The inflows and outflows over the span of the program sometimes leave the project financially challenged.  The Program Manager must develop the necessary financial plans to ensure this is handled wisely, with the support of program sponsor and board.
  6. Program Managers must have knowledge of the organization beyond managing projects.  Knowledge of the organizational culture, operations, background, etc., are key for program success.
  7. Benefits realization in programs sometimes come long after the program itself is closed.  This is challenging as the program manager might have to plan for sustaining the momentum for the changes brought by the program long after he or she closes the program.
  8. Risk Management on projects is key, but it is more so on programs.  There is a lot of uncertainty on programs.  For example, not all program components might be known at the beginning of the program.  So estimation becomes difficult early on, causing funding to become a potential issue.
  9. Balancing between controlling program components (projects and operations) and allowing project managers enough autonomy is a challenging task.  Project Managers need room to maneuver on their project, but the program manager must keep a close eye on the performance of the project.
  10. Benefits realization means always keeping an eye on the big picture, and having the wisdom to see the long term vision.  This becomes the responsibility of the program manager, even when everybody else seems focused on short term issues.  Project Managers deal with shorter term issues than program managers.

For More about Program Management and Program Management Certification, follow this link to one of my youtube videos.

Posted in Uncategorized | Tagged: , , , , , , , | Leave a Comment »

Is Project Management Moving Away from Analytic Models?

Posted by Ammar Mango on January 23, 2014

Summary:  When I learned Project Management in Undergraduate and Graduate studies, I remember scheduling taking a center stage.  We were taught everything about scheduling, its models, relationships, PERT, CPM, PDM, dependencies, etc.  Today, most projects are succeeding or failing, for reasons other than how “perfect” or “imperfect” the project schedule is.  Furthermore, I feel that the love that engineers have to the scheduling and its intricacies has  counterproductive effect on the project.  This is why the role of scheduling and its value needs serious and brave reconsideration.

When I teach project management for PMP candidates, you can immediately see how engineers and programmers love the part related to scheduling; it is common sense to them, and puts them in their comfort zone: 1+1=2.  However, in the context of the project management knowledge, scheduling techniques are taking less and less percentage over the years.  The domains of knowledge of project management are being enriched in the areas of stakeholders management, soft skills, leadership, risk management, etc, and less attention is given to scheduling.  This is important as project management is about value, people, and interactions, beyond what a scheduling model can describe. In Project Management, one of the most detrimental things a manager could do to the project is to assume that the project models, including the schedule, to be the absolute truth.  Models are there to help us comprehend reality, not to replace reality.  So, to rely completely on analytic models in project management is like fooling oneself that everything in project management is as simple as a formula to calculate the forward pass. Understanding the way of thinking of your key stakeholder, or making sure they can imagine the value the project will deliver might be more important than any schedule or cost baseline.  Also, a market that is stalling, or a cash-flow that is dwindling due to external factors, might not show on your schedule or cost forecast if you do not stay alert to what the world is telling you about the project and its environment. GIGO my professor used to tell me about models: Garbage In Garbage Out.  What we put in the model, and what we know about what the model cannot represent might be more important than the model itself.  KISS another professor used to tell us: Keep IT Simple (lets skip the last S), and definitely this is more relevant today than any other time.  if we start complicating models, then changing them will be become very hard, especially in the fast paced world of today’s projects. So, what is a project manager to do? in addition to the above advice, it is important to stay close to the stakeholders, get used to working in a grey zone of “mushy” information that is not a product of a cast in stone analytic model.  This includes “feeling” the vibes from the stakeholder, learning to build decisions on bet available information, not just data.  Also, keep your toughest critics close, so they help you improve on your plans.

Posted in The PMO | Tagged: , , , , , | Leave a Comment »

Get your Project Dynamics in order

Posted by Ammar Mango on December 28, 2013

tempballs“Managing projects is about managing the competing demands.” is a statement to be expected in any project management course.  Unfortunately this statement is not completely accurate and can be greatly misleading.

Competing demands are defined as: Time, Cost, Scope, Quality, and Human resources.  They represent most of what we call the “Project Management Knowledge Areas” as defined in the Project Management Body of Knowledge (PMBOK).  The PMBOK is the defacto standard for project management published by the Project Management Institute (PMI).

Managing projects is no longer about Time, Scope, and Budget.  Neither is it about the competing demands or any of the PMBOK knowledge areas.  It is more about using these tools to create and preserve the right “Project Dynamics” to ensure a successful project.

“Project Dynamics” is a term that you will not find in theory books, and used here for the lack of any other term.  Project Dynamics is a group of forces affecting a project.  So, they vary from one project to the other.  While most projects share similar project dynamics, their effect, importance, and extent vary widely by project.  Project Dynamics in sync result in project success.

Project Dynamics are: Sought value, history, driving forces, circumstances, and emotions.  All of them are perceived through human eye.  So, human perception is the key for project success.  It is through perception that we judge success after all.  This perception is affected greatly by these dynamics, and more importantly their interactions.

Let us look at some of these dynamics and what they mean:

Sought Value is the answer to the question: “Why are we doing this project?” Remember that the true answer to this question will vary from one stakeholder to the other.  So we need to know and understand the answer from all the key stakedholers.  We need to also know that the first answer we get from the stakeholders is the wrong one.  For example: “We want to upgrade our financial system.” This is not a real value of the project.  The real value is the answer to the question “Why do we want to upgrade?”

Driving Forces is another of the project dynamics.  Driving Forces are the fuel that make the project move, so to speak.  This includes people who want this project to happen, it includes a strategic theme, any legal requirements, cash, resources, technology.  It includes anything that is pushing (like resources and cash) or pulling (like strategic goals) the project forward)

Circumstances include the company, culture, market situation, and the surrounding effects that can hinder or support the project along its way.  For example, I know a friend who created a great business solution about three years before the market demanded it.  His company went bankrupt.  Not because what he sold was not value, but because it was not there at the right time.  In this case it was there too early.

Another important Project Dynamic is Emotions.  Emotions are a big driving force for us humans, and since projects are about people, you can be assured that the emotions of the stakeholders involved in the project play a big part in meeting its objectives.  A team that lost its morale, or does not have faith will fail even the best ideas.  Also, if the project does not arise an emotion in stakeholders, it will be hard to push them to pay for it, or spend time on it, or support it.

There are other project dynamics but I tried to mention here some of the common ones.

Now, let us see how project dynamics, not competing demands (time, scope, budget, etc) affect project success:

So, to say Cost is a key determinant of project success would be a bit unrealistic.  In reality, it is the perception that the value received is well worth the cost paid, and that the perception that the cost paid was justified.  So, even if project cost goes over budget, stakeholders will deem the project successful if the value is well worth the cost paid, and if stakeholders believe that the overrun in cost was justified.  It is Project Dynamics that deemed the project successful.

Same thing applies to scope.  So what if you do not perform the scope defined in the original plan? The plan keeps getting modified anyways.  And we know that after starting the project, we might find that what we really need is totally different than what we originally scoped.  Again, Project Dynamics determine how the story of the project will go; is it a success or a failure.   In this case, if stakeholders see they are getting more of the value they seek from the new scope, and that the change in scope is justified, and the Driving Forces (another dynamic) behind the project (like capital, sponsorship, strategic direction, etc) allow such change, then the project can and probably will succeed.

Most practitioners with a a healthy dose of real project management have already figured this much out, that the project dynamics, and understanding how they interact, trumps the old and generic “time- cost- scope” triangle of competing demands, any day and any time, as determinants of project success.

So what is the role of Project Management processes in this complex project environment? The Project Management Processes are a tool to help us manage these project dynamics.  They are not a goal in themselves.  So, creating a project schedule is not a goal of the project.  It might be a requirement from the PMO, but only because experience shows that having a  schedule baseline improve our chances of finishing on time.  Not because we must have a schedule as an output of the project.  We need to have a schedule, to help us succeed in our project.

Consider the project management processes as tools in the warrior’s (Project Manager’s) armor.  Which tool to use, when and in what combination can only be effective after understanding the dynamics of the project, and accordingly manage.

Many companies are building their own Project Management Methodologies based on international standards.  These companies should understand the project dynamics around their projects and organization, and accordingly build their methodology around these dynamics, not around generic processes.  This is a true measure of organizational project management maturity, more than any generic processes or methodologies.

Posted in The PMO | Tagged: , , , , , , , | Leave a Comment »

Why Successful Project Management is so Illusive

Posted by Ammar Mango on August 26, 2013

A lot of what experts say seems like common sense: “Plan well,” “communicate with team,” “manage your stakeholders,” etc etc.  All of it seems like the old adage : “Buy low sell high” kind of advice.  We all know we need to plan.  We all know that communication is important.  Yet, in real life, none of that takes place; we do not plan and we do not communicate.  So what gives?

In reality, many of us abuse project management.  Every time we have a project, we go about it the same mechanical way of filling the necessary forms with the necessary information, get approval, start work, and collect and report on progress, and handle issues and risks.  Yet, the project fails, again.  The reason might be that we did all the “mechanical” parts of  project management.  There is a missing important part: The intelligence.

Project Management is not about filling forms.  All the tools we use in project management are just mechanical tools to help the intelligent navigator carry through the project successfully.  The mechanical tools without the intelligence are useless and here are examples:

– How many projects do you know, where project management forms were filled and projects were managed, but the whole business model behind the project was flawed? ie the company ran out of cash, or the market did not accept the product?

– How many projects do you know had reports that clearly stated certain major risks in manager reports but no one took action until the risk hit the project?

So, everything we do in project management is meant to help an intelligent pilot and team navigate through the project risks.  if that intelligence, attention, commitment, and leadership are not there, then project management is a waste of time.

Let us take this a step further.  I believe that the avalanche of documentation and information collected on a project might be to the detriment of the project.  For example, Developing a detailed schedule might be a waste of time on some projects.  Other projects estimating and setting a detailed cost baseline might be a waste of time.

The other side of the coin is that not doing enough documentation is detrimental to the project.   Sometimes for convenience purposes we assume we do not need a schedule when we really need one.  Then we get into trouble.

So, too much documentation is as bad as too little.  Too much detail in irrelevant parts of the plan are as bad as too little detail in the relevant parts.  A judgment call is needed to determine how much is necessary, and in many cases that judgment call is flawed.

This is the trick in project management.  To know what the real challenges and opportunities on the project are and gear project management towards exploiting these opportunities and dealing with the challenges.  If the key is the cost issue, then put a lot of effort on the cost, and reduce information from other factors that are not as important.  If the schedule is of essence, focus more on the schedule.  If the issue is on the soft side managing client expectations, then put more effort there.

So, the intelligence, commitment, and leadership are prerequisite for successful project management.  Also, the art of knowing how much or how little information is needed in each of the project phases, and how to manage this information, are also prerequisite to successful project management.

This is easier said than done, and this is why project management will remain an illusive art more than an engineering science.

Posted in The PMO | Tagged: , , , , , | 1 Comment »

What I learned at PMI Congress 2013 in Istanbul

Posted by Ammar Mango on May 2, 2013

I have not been to a global PMI congress for over 20 years now.  So it was about time for me to attend again and it was a learning experience.  The choice of location, Istanbul, was excellent; beautiful city that represents the trends and changes we are witnessing in a changing world of emerging markets.

I will try to sum up my learning  briefly, and hope to be able to cover some of the more important points in later blogs.  I do not think any of the items below are earth shattering, but they give telltale signs about where the profession is heading, and how to take advantage of the opportunities these trends offer.

The main theme for the congress to me was the new role for a project manager, beyond being just a manager.  Many of the keynote speakers made strong connections between project managers’ success and their ability to grasp and act upon the project from a strategic perspective that includes understanding the markets, policies, culture, politics, and business strategy surrounding the project.  There was consensus that the project manager has to act more as an executive than a manager to succeed in today’s fast paced work environment.

There was a lot of focus on the importance of agile as a business philosophy, not merely a development or management technique.  The focus was on repetitive fast paced moves, if you will, towards a goal, while keeping the stakeholders on board and revisiting and refining requirements and direction continuously and effectively.

The project manager as a leader and influencer also took center stage.   Jay Leroy Ward talked about the 14 skills a project manager must possess to succeed, and all of them where on the leadership and communication side of things, not on the hard skills side of project management.  He and many others emphasized that training efforts in organizations are more geared towards hard skills, and away from the soft skills required for success.  It does not mean that hard skills are not important, but they will be much less effective without the right leadership and communication skills.

Another theme in many sessions was the importance of collaboration, networking, and trust among stakeholders.  They are the real drivers for project success and are quickly replacing traditional modes of governance like hierarchy, direct authority, and we-they or win-lose relationships.

A related subject that also was discussed was the focus on quality rather than quantity especially in working hours, relationships among team members, and management.  Pushing people to work “harder” and longer hours is becoming something of the past, as more organizations are finding out that effectiveness is not proportionally linked to number of hours worked.

It is pleasant and reassuring to see the models of fairness, trust, and collaboration still reign with the professionals and experts even with the difficult situation of the economy worldwide.

There was lots of witty humor and use of YouTube and media in the presentations which was refreshing and fun.  May of them focused on cultural interfaces and challenges.  Here are a few:

– The offensive translator

lost in translation

Dinner Etiquette

And finally a picture shared by Jay Leroy Ward on the importance of trust among team members which shows my favorites: The three stooges



Posted in The PMO | Tagged: , , , , , , | Leave a Comment »

“Certified Project Executive” Anyone??

Posted by Ammar Mango on March 26, 2013

I was reading earlier an article in the PM Network issue this month, that quotes Mr Mark Langley, Project Management Institute – PMI President, challenging audience to become “Project Executives” not only Project Managers.  This really clicked for me and I think he hit the need right on.  We need a level of project management competency that ensures leadership at the BUSINESS level of the project.  This is how I understood Langley’s comments and this is the need that I see on the ground.

If one looks at what the organizations consider as the best project managers, they are are those who:

1. Understand the Project Management Knowledge

2. Know how it is applied

3. And most importantly know how to masterfully apply it or lead a project management team that applies it in a business setup.

I think the PMP certification can shed light on the first two points, but might fall short from guaranteeing the third.  It is one thing to be a certified Project Management Professional (PMP) (All rights reserved to the Project Management Institute – PMI, but it is another thing to be a competent project manager.  I am a proponent of certification and believe that the PMP certification has served the industry and the project management professionals very well, myself included.  However, many companies are seeing the need to differentiate between someone who has 3 years experience in project management and passes the PMP exam, and someone who can really lead the business of the project.

For example, as a PMP, one might know:

– How important a project charter is,

– When it must be developed,

– Who should be involved,

– What should be in it.

But still a PMP might not be able to develop a value adding project charter, or evaluate the quality of a project charter.  Just because a project manager knows a project charter should include clear definition of the business need, does not mean that manager know how to articulate it.  I have seen project charters that are a waste of time, as if they were written just to get checked off someone’s checklist.  Sometimes because the project manager does not really believe in its importance, and other times because of external pressures of others who refuse to cooperate or subscribe to its development and chartering.

On top of what is required to be certified as a PMP, a competent project manager, also needs the following essential attitudes, competencies, and abilities:

– The Project Manager has the conviction that this is an essential document

– The Project Manager has the leadership abilities to use influence and resources to get others to subscribe to the charter and its development

– The Project Manager knows how to develop or ensure quality value adding content is in the charter, not just a space filler kind of information.

– The Project Manager knows how to communicate the charter and when to refer others and self to it throughout the project

– The Project Manager knows how to use the charter to improve chances of project success throughout the project

The above skills and competencies are needed for all other tools and techniques of project management including managing stakeholders expectations, developing a communication plan, managing conflict, etc.

In the big scheme of things, I see the PMP as a good place to start to acknowledge a project manager who understands how the PMBOK should be applied on actual projects.  But then, there is the project manager who does not only know how, but a master of this application in real life.  At this level of competency, the project manager should be tested in the ins and outs of the technique, the outcomes, and the actual development of the outcome, and how to use it.  The PMP exam is not designed that way in my opinion.  To give an example, the PMP exam asks questions that ensures I understand the importance of the communication plan, its main components, who should be involved in developing it, etc, but I can know all that and not be able to write a decent communication plan.

When I keep using the word masterfully, it does not mean “perfectly.” There is no black and white in the management science and organizational theory.  There is always a better way, and room for improvement.  So, “masterfully” means the wisdom and experience to utilize what is available to the best of one’s ability to create value, and be ready and flexible to modify as needed to meet needs and expectations.

I understand the difficulty coming up with such new certification can pause, as far as logistics, design, etc, especially when trying to apply this globally.  However, I believe it must be done.  At a high level, this is how such certification might look like:

1. Pass a preliminary test that shows that they have sufficient PM knowledge, leadership abilities, and experience.

2. Qualifying application, CV review, and multiple interviews including some kind of a 360 evaluation

3. Read assigned reading which will include books, papers, etc pre-selected to cover the key focus areas of the certification.  There will be no one reference.  Also, for tose who prefer to learn in a course setting, a training will be provided on each focus area online and classroom style, but they will be optional not mandatory.  The key focus areas should include:

– Organizing and preparing for initiation

– Project Initiation

– Project Charter Development

– Securing Management Support

– Managing Client Expectation

– Cross Organizational Stakeholder Management

– Initial Project Setup

– Risk Management, beyond the mechanical structure, and into engaging stakeholders, clarity, commitment, and decision making

– Defining the project organization structure and its support structures

– Managing Stakeholders Expectations

– Scope Definition and the skill of writing a scope statement, building the WBS, and writing the WBS dictionary in way that serves the WBS purposes

– Developing a baseline at the right detail level, and additional derivative baselines for different project working levels

– Distributing work and project ownership

– Managing Subject Matter Experts and resource managers

– Project Reporting including report design based on level of reporting and stakeholders needs

– Estimation techniques and its relationship to type of work, team motivation and type, and other behavioral factors, and linking estimation with risk management and progressive elaboration

4. Attend a workshop to cover the focus areas that the certification focuses on.  The workshop will allow discussions of these areas and presentation of the take home assignments in the next step.  The workshop will be 5 days.

5.  Take home assignments to develop necessary artifacts based on a given case study. These will be presented by candidate to panel of experts at the end of the workshop.  The review will be elaborate, where a day will be assigned per candidate for the discussion and review of the candidate’s work.  The work will be scrutinized and this will be the most challenging part of the certification process.

5. Final exam, not multiple choice, where candidates have to demonstrate their ability to deal with open scenarios that do not have a clear “correct” answer.

6. Once passed, the candidate will receive not only a certification, but a presentation and media from certifying body about the skills and abilities of the candidate who carry the certification.  The candidate will be certified only in the areas he or she demonstrated competency in, so it does not have to be all or nothing.  So, If I am competent in managing stakeholders expectations, but did not reach that level in estimating, I will get a certificate of competency that lists just the areas I covered.  Later, as my competency is verified in other areas, they are appended to the certificate.

7.  The certification is a lifetime certification, not subject for renewal.

I believe that the main driver for this certification will be companies who hire the certified professionals, and how easy the certification makes it to select the practitioner who can run their project as a business, not merely has the project management knowledge and how it is applied.  Instead they can apply what it takes for projects to succeed and provide value.

I know that such level of complexity is difficult to achieve, but if this is what the industry needs to grow and mature, it might be necessary to overcome the challenges and come up with such certification.

For PMP to continue its success as a certification, we need a distinguishing certification that acknowledges the big difference between a three years experienced project manager who learned the structured PM approach and had a brush with its application, from the competent project manager who also knows the structure, but is a master in applying it in real world projects.

Posted in Understanding OTHERS | Tagged: , , , , , , | 1 Comment »

Thirty One Ingredients of Failed Projects

Posted by Ammar Mango on March 24, 2013

Failed projects have a lot in common.  Here are the things I most commonly find in failed projects, the lower the number the higher the impact:

31. Focusing on the mechanical part of planning (critical path calculations, the schedule model, etc)

30. Ignoring proper definition of “project success” and “project and product quality” by all involved

29. Making promises you cannot keep

28. Lying

27. Thinking you are smarter than everybody else

26. Dealing with the client as an inconvenience

25. Focusing on finishing the project (instead of providing value to the client)

24. Not reading every single project related document (especially business and high level technical)

23. Being oblivious to project developments

22. Disconnect between project manager and client

21. Disconnect between project manager and sponsor

20. Uncommitted client

19. Uncommitted sponsor

18. Uncommitted team

17. Trying to win popularity contests instead of holding everyone accountable

16. Ignoring subtle and not so subtle messages from stakeholders especially client

15. Avoiding the client and how satisfied they are of your work personally and the project

14. Getting stuck in busy work and ignoring big picture (like an ostrich sticking head in sand)

13. Being afraid to say no

12. Ignoring the contract and project documents

11. Rough attitude (thinking that by being cruel people will fear you and do what you want)

10. Soft attitude (unable or afraid to reprimand)

9. Hiding in your cubicle

8. Taking progress reports as accurate (without double checking)

7. Victim mentality, refusing to take responsibility for mistakes and errors

6. Blame game, blaming others and not standing up to your part

5. Hogging credit, and not giving credit to the team and other stakeholders.

4. Mistrust others

3. Assuming you can win alone, and let client and suppliers and team lose

2. Quitting early; assuming there is nothing you can do and letting the project go south

1. Fear of failure; you will never get anything meaningful done

Posted in The PMO, Uncategorized | Tagged: , , , , , , | Leave a Comment »

Thirty-ingredient recipe for successful projects

Posted by Ammar Mango on March 20, 2013

Projects require certain ingredients for success.  They do not guarantee success, but the more you have of these ingredients the better are the project success chances.  Here are the top 30 ingredients I see in successful projects.  All of them are important, but the lower the number the higher the importance.  How many of these does your project and its environment have?

30 User Friendly Collaborative Web Based Software
29 Document Management
28 Issues & Risk Management
27 Control, Progress Analysis &Reporting
26 Project Baseline (especially WBS, WBS dictionary, and Schedule)
25 Project Charter
24 Project Management Training (Preferably on Custom Methodology)
23 Project Methodology
22 Team Buy-in
21 Project Management Awareness
20 Communication Planning and Management
19 Big Picture view of project
18 Project Awareness & Marketing
17 Engaged Subject Matter Experts
16 Skilled Project Manager
15 Capable PMO
14 Engaged Client
13 Engaged Project Sponsor
12 Cross Organizational Project Steering Committee
11 Upper Management Support
10 Clear Project Objectives
9 Good business case
8 Positive Attitude
7 Trust
6 Fairness
5 Clarity
4 Honesty
3 Integrity
2 Competence
1 Good Intentions

Posted in The PMO, Uncategorized | Tagged: , , , , , , | 4 Comments »

No one can implement the PMBOK

Posted by Ammar Mango on November 9, 2012

The PMBOK is short for the Guide to the Project Management Body of Knowledge, which is the standard of choice for most project managers worldwide.  It is published by the Project Management Institute (PMI) and is probably among the best-selling books in the field.  Anyone who applies for PMI certifications including the Project Management Professional (PMP) must read the PMBOK and be intimately familiar with it.

I respect all the effort that has been put into developing this important standard and had the honor to be allowed to review and give my feedback on many of its versions, including the fifth edition, which is soon to be released.  The PMBOK, as useful as it is, can easily be misunderstood as a project management methodology that can be applied by organizations worldwide.  This is not true.

Let me explain with a story from my experience.  Over ten years ago, I was asked to come in and assess a newly developed project management methodology for an organization.  They brought in an international consulting firm to help them develop it as part of a project management improvement initiative that cost over two million dollars.  The reason I was asked to assess is that even after six months of making this process available to the organization project managers, no one is able to successfully implement!  not even partially, except of course sporadic use of few processes here and there.

I was curious to look into why this is happening.  As soon as I started reading the document, I could tell that it is not a methodology; there are no phases, no project life cycle, no entry / exit criteria, and none of the things that should be clear as soon as you look at a methodology.  All it was is a group of processes that talk about how to manage different knowledge areas of project management.  What was more shocking is that the content was strikingly familiar.  It was really an improvised interpretation of the PMBOK.  There were no links between the project life cycle for the organization and the processes, there was no clear sequencing of processes especially for planning, there were no directions to project managers and other stakeholders on how to use the document, there was clear direction on where to find latest edition, how the document will be improved, etc.

The PMBOK is a standard that can be used to guide the development of the organization’s project management methodology but cannot replace it.  It is impossible to implement the PMBOK as is for an organization.

How can you tell if the methodology your company developed is a real methodology not a mimicking of the PMBOK?  Here are a few tips:

1. The methodology should clearly show the project life cycle at your organization, not the PM process groups, as a guide for the project manager to follow.  It should show clear entry and exit criteria from and to each phase of the project life cycle.

2. The methodology should answer the questions of how project initiation, planning, executing, controlling, and closing will take place at project level and phase level.

3. The methodology should consider key themes of project management, like iterative processes, progressive elaboration, lessons learned, continuous improvement, professional ethics and conduct, etc.

4. The methodology should be applicable, not overwhelm project manager with towering documents that he has to read all through and interpret to be able to manage a project.  In that case, many project managers will not read, and each will interpret differently.

5. Use technology to make the methodology more accessible and user-friendly.

6. Ensure the methodology considers the tools, techniques, and templates to be used to carry out its processes.

7. Ensure necessary approvals and workflows are taken into consideration.

8. Ensure that the process is scalable and can be built upon, and takes into consideration current levels of maturity AND sought after new levels of maturity in a gradual practical and implement-able improvement stages.  This could be part of a PMO plan or improvement, implementation or launch plan.




Posted in The PMO | Tagged: , , , , | Leave a Comment »

%d bloggers like this: