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

Archive for the ‘The PMO’ Category

The Project Management Office function is a relatively new comer to the organizational structure. The term itself became popular only in the past decade and it defines a unit that is responsible for varying project management functions in the organization.

Project Management with Ten Elephants in the room

Posted by Ammar Mango on August 18, 2014

download“So should we start with a meeting to review project charter, or shall we wait until the scope statement is more clearly defined?” asks the Project Manager in a typical give and take that takes place at the beginning of a project.  Realty is that, most probably, it does not matter.  Or at least it does not matter as much as other so important issues that need to be addressed, but are ignored.  These are the elephants in the room that get ignored at the beginning of every project.  These issues are so big and obvious, but maybe because of their sheer size, project managers, clients, and suppliers,  prefer to ignore them as if they do not exist.  Guess what: They do exist and they are the biggest challenges facing the project, and lead often to project failure.

The elephants in the room are all man-made.  They are all about people.  This is another reason why they get ignored.  Most of them are caused by project influencers that no one wants to alienate.  This results in sacrificing project value to address other factors like “looking good,”
preserving status, gaining favors, or being comfortable in complacency.  Here are the top ten elephants that are places in the room on new projects, and get ignored by project stakeholders:

Elephant #10-Pick a big name: A project supplier is chosen because they have a good name, regardless of whether another supplier has more relevant experience.

Elephant #9- Cutting Corners: Trying to avoid risk, by taking shortcuts and downplaying key parts of the work, just to finish work on time and get payments

Elephant #8- Bureaucracy First: Worrying about deliverables and documentation, instead of results and value.

Elephant #7- Dangerous Leverage:  Assigning juniors the work of seniors to save on project cost, then use politics and sales savvy to get acceptance

Elephant #6- Fancy software and shiny hardware: More attention is given to purchasing brand name software and hardware instead of focusing on improving performance, change management, and learning.

Elephant #5- To Accept or Reject is merely a question:  Trying to control project when no one internally has the ability to review completed work.  Sometimes external consultants are hired to review the work but they also do not have as deep knowledge as the supplier, and they end up limiting the supplier’s ability to deliver value, instead of assuring quality.

Elephant #4- Spending the Budget: Clients who are not sure what they want but have a budget that they must spend, and need to show quick wins for spending the budget.  This results on tactical improvements being worked on instead of strategic improvements.

Elephant #3- The Hat does not fit: Roles and responsibilities on the project are distributed politically instead of technically.

Elephant #2- “Whatever”: Lack of interest in the project, especially when undertaken due to an external mandate.

Elephant #1- The Political Game: Project is lost in internal struggles where its value is judged based on who sponsored the project, not the actual value it delivers.




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

Operations and Projects; back together again…

Posted by Ammar Mango on February 9, 2014

…And that is OK.

Many project management practitioners always complained in the past of the lack of distinction between project work and operations work of an organization.  A case in point is the hand over phase agony of turning the completed deliverables to its owners to become the responsibility of operations team, vs project team.  This was a big problem and caused many project failures, and it still would be a problem if it is still handled the same way today.  Luckily, we are seeing organizations avoiding this pitfall, and becoming more mature in their ability to organize project work into projects, and to recognize when other work has to be left for operations.  However, this is not the end of the story.

Today, the line between operations and projects is becoming blurry again, but in other, more positive ways.  For example, the PMO is becoming more interfaced with other operational departments of the organization, like finance, HR, procurement, etc.  Also, the PMO, even though it is handling projects, it is being recognized more and more as the operational function that it is.  While some PMO’s are temporary, serving a project or a program, most organizational PMOs are permanent, serving the organization on an ongoing basis. So, this makes it more an operational function.

With that recognition by the organization, the PMO is becoming more accepted among departmental managers as a function of the organization like other functions.  Of course I am talking about organizations who were able to successfully implement their PMO and sustain it.  Because those who are still struggling are another story altogether, and there are still quite a few out there.

Back to our sustained, value adding PMO.  There is a trend today for PMOs to step outside the “projects management” into two important areas: The first is portfolio management.  While it is theoretically one of the key functions of a PMO, in real practice, most PMOs do not handle most of the defined portfolio management functions.  The second area is operations.  Many PMOs will have to step up and handle procurement, financial, and HR issues, in cooperation with the respective responsible departments.  The standard way that these departments handle these functions are more geared to operations, and in many cases are not sufficient from a projects portfolio perspective.  This is why it will become essential for the PMO to step out of its traditional boundaries into operational areas.

For this to happen, more leeway should be given tot he PMO to get involved in operational issues, outside the PMO jurisdiction, and to be empowered to interface with other functions and seek solutions to common cross functional issues.  Moreover, the PMO can play a leading role in such improvement initiatives as it has a unique cross functional perspective of the organization and its “value chain” if you will, that other functions might not have.

Also, the character and capabilities of the PMO head will play a big role in the realization of benefits from such PMO involvement.  The PMO manager  needs to be a veteran with the conviction and capabilities to make such interfaces a reality, rally the organization towards improvements, and sustain these improvements.

This is a tough quest for the PMO and might prove more challenging than it seems.  The executives see the PMO as primarily tasked with handling the project portfolio (usually billable work) and keep that as focus, over any internal improvement initiative.  So, the PMO manager  must strike a balance and address change in perception and behavior required to sync operations and projects in the overall corporate scheme.

Posted in The PMO, 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 »

How do I prepare a fifteen minute presentation of a project business case?

Posted by Ammar Mango on November 25, 2013

This is a good question I got and thought to share the answer with everyone, as I get asked this question often.

The most important thing is to start with “drawing a big picture:” so, before you start working on content so diligently, stop and ask your self the following questions.  Take your time answering them and do not rush them so to get to the “important stuff” which is preparing the presentation.  This IS the most important thing in a presentation, not the content.  So here are the questions:

1. What is the context? 

– What is the purpose of the presentation?

– Who is attending?  their background, ages,interests, influence?

– What are your goals from the presentation?

– What are the goals of those attending?

– What does an “excellent presentation” look like?

– What is the ideal outcome your and your audience and stakeholders want from the presentation?

– Are you presenting alone, or is your presentation part of a bigger longer presentation?  what you say it will be different based on this.

2. find a theme for your presentation.  To do that here are some tips:

– What is it you want to tell these people?

– What do you want them to do?

– Can you state the above in a simple few words sentence?  can you present it early, and reiterate it so it sticks?

– how hard is it to convince? are you driving a tough bargain?  or is it an “easy sell”?

– What are the main objections and questions your audience will have to prevent them from “buying” your proposal?  do you have convincing answers for them (if you are not convinced chances are they will not be convinced)?

3. Time to develop an outline

– Go now to Powerpoint

– Start creating an outline (table of content) for your presentation.  do not be traditional.  focus on what they want to hear, do not put “filler” information, like formalities, useless info, etc.  When  you put the outline, consider that each slide answers an important question, concern, or interest for you audience to accept your proposal.  otherwise, it is a waste of time.

– A good generic outline for a business case, brief one, is:

  • Title,
  • Introduce yourself (if you are good, you can do this in a creative way that relates to your project and get people attention),
  • Goal from presentation,
  • Agenda (with minutes for each item), here you should tell your audience if you want them to wait until you finish or to ask you as you go.  it depends on how good they and you are in managing the time.
  • General info about the project, who what where why when (very briefly)
  • Draw a picture of what life will be like when the project will be completed (value from the project)
  • Why it is the best alternative (you can either focus on your project, or on subliminally and tactfully show how other alternatives do not work as well.)
  • Challenges expected (HERE BE CAREFUL, you can use this to show them thatyou know their concerns and that they will be addressed properly).  Be brief unless it is a tough sell and they are really concerned.
  • Reiterate value briefly but convincingly
  • Tell them how they can continue the discussion or get more info
  • Ask them for action.  This can be titled NEXT STEPS, WHAT IS NEEDED, etc.
  • Q and A

4.  Now get the “beef” for your presentation.  the less words the better, the more graphs and pictures the better


– Do not apologize for  anything while presenting.  you look weak.  never apologize for not being prepared, for not having info, nothing what soever

– Be confident. breathe and smile.  it helps

– Do not read the slides.  put a word on the slide or a picture that is inviting, then talk about it

That s it .  Good luck

Posted in The PMO | Tagged: , , , | 2 Comments »

Because the contract is not enough

Posted by Ammar Mango on November 10, 2013

I always get asked this question from trainees in my project management courses: “Why do we need a project charter or a project plan if we have a contract?”

There are many, not one reason.

First, the Need for Clarity. Contracts are made as legal binding documents for legal purposes.  The project charter and plan are not developed for legal purposes, but to ensure delivery.  While the two parties of the contract are set in the contract as adversaries (almost), the plan is more of a collaboration between both parties to get the work completed successfully, as a team, not adversaries.

Second, the contract might not have the necessary details to clarify the scope and other plan elements.  It is an agreement between two business parties to get the project completed, but the technical people and the project manager who lead this effort need now to meet to get the work relationship defined from a work perspective, not just business perspective.  While I am a big proponent of project managers and team being business savvy, but business savvy alone does not get the job done.

Third, the plan in the contract usually has key elements of the plan at a high level but not a workable plan.  To organize work , the project needs a workable plan that everyone can follow.  Organization and structure is needed to get the job done and what is in the contract of the plan is not enough to do that.

Fourth, the client needs to be involved in this plan and not just be a referee or a judge.  Unfortunately, many clients assume that they have now a constitution (the contract) and it is time to lay judgment on the supplier based on the constitution, so to speak.  In reality the worst thing the client can do to lose value from the work is become a judge.  A client is a partner, who treats a supplier as a partner, to ensure mutual benefit and win-win relationship.  A client is usually afraid that being a partner will make him vulnerable if the supplier does not perform.  With this kind of attitude, the project cannot be heading towards creating value, even if it formally gets completed.

That’s it for now.  What do you think?

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

Social Responsibility, Again

Posted by Ammar Mango on October 17, 2013

It is dangerous when social responsibility becomes an occasional task that we get over with; like a charity dinner, a charitable donation, or  a volunteer job.  with this type of definition, companies and individuals feel they have a carte blanche to be irresponsible socially in how they deal in business. Is this becoming a trend? and if yes, what is the solution? and what is my role as an individual to reverse this mentality?

We all hear the complaint about corporate responsibility statements, where companies say something and do the exact opposite.  One such global company I dealt with has in their published statement the following: “We have a responsibility to be an active member of the communities in which we live and work.” I had a phone interview with their HR manager about a year ago, about a capacity building project in one of their middle eastern locations.  During the interview, I raised the need to build awareness in an important ethical challenge that might need to be addressed.  Her answer was clear and firm “If I was in my headquarters, I would agree with you, but in this country, I have a job to get this done and leave, without getting into their cultural issues.” Is this speaking from both sides of the mouth? or an ill informed employee about her company CSR statement.  Both are dangerous, as she is a ranking director in her company.

There is also at the individual level:  We see on the news charities and events sponsored by individuals who give generously to a good cause.  A closer look at how they carry their business might not reveal the same level of corporate responsibility. Of course not all, but a considerable some.

Social responsibility should become a way of life.  A way to assess our daily interactions with the world around us.  If some feel they are too small as individuals to make a difference then probably they are.  Not because of their position or rank, but because of how they think.  If you think you are too small to make a difference then you are.  Not because of your situation, but because your self talk is stopping you from doing your duty.

As individuals, we need to plan our social responsibility like we plan our work.  There has to be a general policy of ethical values and standards that we want to live by.  Then we have to put a one to two year plan of social responsibility goals that we would like to achieve.  Then, work on weekly goals that get you to what you want to achieve.  Finally, one can manage these CSR activities on the to do list.  The same one used for business tasks.  Make sure some of your social responsibility tasks, take priority over some of the business tasks.  It feels good.  Try it and enjoy being socially responsible!

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

The quest for the technical project manager

Posted by Ammar Mango on September 20, 2013

It is becoming less common but it is still out there; the demand for the technical project manager.  To deny the role would be unrealistic, but to assume that it is all that is needed as far as project management, that would be more unrealistic.

From experience, and some of you might agree, that a technical project manager cannot work alone, without someone playing the role of the “business” project manager.  Usually companies figure that out too late, or even never figure it out, and blame failures on incompetent resources or project managers.  The truth is that the main problem is in the attitude of management and how the role of project manager is looked at.

Some say that the term itself “technical project manager” is counter productive, since a project manager is a project manager, and should take care of business and leave technical to technical.  Others disagree completely, they want a project manager who is as knowledgable, if not more knowledgable in the technical aspects than the technical team.

Let us start with the idea of a technical project manager.  This is a relatively older idea than the business project manager, and maybe why it is still evident especially in less mature organizations, and organizations that are not open to change or at least fast change.  Technical project managers are also more common in smaller organizations, where the company has not decided yet to invest in higher rate project manager.  Business project managers on average get paid more than technical project managers.  Also, smaller companies who do not have the experience and the commitment to project management are still not sure about the value a business project manager can bring to the table.  Also some industries seem to be focusing more on the technical project manager than others.

A point of caution here, many ask me: “if you really believe in a non technical project manager, why do you focus on expertise in the technical field when you advertise for project manager positions?” There are two parts to the answer of this very good question.  The first is that it is very important to differentiate between expertise in the field and technical expertise in the field.  For example, I insist on hiring a project manager who is seasoned enough in the industry I am hiring for.   Like for construction, I insist on someone with strong background in MANAGING construction projects.  So, I am not looking for someone who has expertise and strong background as a concrete or steel reinforcement designer.  I am not looking for an electrical engineer who knows circuit design.  I am looking for project management experience in construction.  There is a big difference.  To clarify more, I would gladly hire a project manager with ten years experience managing construction projects, even if his degree is not in construction or even engineering.  Given these are rare and hard to find, but I would hire one if I find him AND if my client is like me looking for project management experience not technical experience.  Sometimes the client insists on someone with an engineering degree.  I usually make my point clear if I have a good candidate who does not have an engineering degree, but if client insists, I usually respect the client wants and look for another candidate.

I was having a conversation with a friend of mine working for a major  manufacturer in Europe.  He was complaining about how the company does not seem to appreciate a business project manager and wants a project manager to solve technical problems.  Again, there are two parts to this issue.  First even if you are a business project manager, that does not get you off the hook when it comes to understanding technical aspects of the project.  Afterall, the team members, client, your management, expects you to be up to speed on technical terms, technical risks, and technical related issues the team might be having.  Now this level of knowledge is attainable without having to get a degree in the technical field, but it definitely requires studying even if independently, and learning about the characteristics of the industry you are working in.  I cannot stress enough the importance of this technical learning.  The further technically you are from the industry of the project, the more reading and understanding and asking you need to do to get up to speed.  Also, the harder it will be for the team to accept you as their leader.  Of course some industries are harder than others.  In construction, engineers find it hard to accept non technical project managers.  However, if you have enough experience under your belt in construction, they might not be as picky about the degree.  In IT it is also the same thing.  One of the best project managers I know in the IT industry has no degree whatsoever.  I learned from this person about project management more than I learned from any single person.  And he was accepted easily wherever he went.  But he had a lot of experience.  Very strong background leading IT projects.  So that makes a big difference.

The second part of the issue of management insisting on a technical project manager is a challenge that management themselves are having.  In the old days, the industry was based on lots of workers (considered hands) and a single or few managers “considered brains.”  At that time, many managers thought that the less brains the better, and the more hands the better.   The industry was based on the innovation of a few intellects, who preferred to keep control of their projects in their hands and have technical engineers manage the “hands” so to speak.  It is sad that people used to think this way, but this was the case.

In today’s industry, things are different.  The executive cannot manage the projects and the engineers, because they cannot be managed as hands.  They are intellects, and their work requires intellect.   They also have rights, speak their minds, and have other options for employment other than the owners’ company.  So, they are less likely to act like machines and more like intellectuals.  Also, with the information technology and automation advances, work has become more about intelligence of operators and users of tools, than the hands that use the tools, or the tools themselves.  So the team members have much more intellects today and need more intellects than the brains of the owner alone.  This is why managing the organization like a group of machines can never work today or would not work for the long-term.    However, some managers insist on still doing just that: treating people as hands.  Many managers think that merely a headcount would be sufficient for a project to succeed.  So, a small IT project requires maybe 10 junior programmers, two senior programmers, and an architect.  They get these “hands” together and demand project success.  Then, they scratch their heads when the project does not work, and start blaming “the hands” for not being competent.  I mean if I had a penny for every time I see this story, I would be a millionaire.  (Well, maybe not a millionaire, but easily would have a dollar worth of pennies 🙂 )

So what does that have to do with the technical project manager or the business project manager?  In the setup above, managers do not feel they need someone to “run” the project and the politics around it and inside it.  They think they have the necessary “hands” and the rest is to get them to labor and work hard.  Those with a better understanding of what it takes for a project to succeed are frustrated with this mentality, and usually run away from these managers and companies.  So, these managers end up with technical people who either have no other place to go, or are content with being just “hands.”  In this kind of organization, you end up with doers who think that hard work alone will get the job done and the rest is automation.  These organizations are either going extinct, or will have to change their ways very quickly to catch up with the rest of the world.  There is not much room for such companies.

By the way, the current recession and tough economic situation parts of the world are going through made it easier for these old mentality managers and owners to make their demands, and to get away with their old ways.  As soon as economy picks up, when other companies flourish, they will probably be on their way out.  If not, they will keep struggling trying to make ends meet to no avail.

What is sadder is that many of them will not even know why they are going out of business, when they do.  they think it is a weak market, too much competition, tough clients, or incompetent employees. They never blame themselves and they never learn from the experience.

So where does this leave us? Who do you want to run your project: a business project manager? or a technical project manager?  There is still a choice to be made as both are out there in today’s market, but I do not know for how long.  The problem is that when technical project management does not work anymore, it is not easy to just switch to business project management, because the company will have to get acclimated to that kind of environment.  For companies that are less used to change, it might require three years or more years for an average size company, If they ever figure out the real problem they are facing, and if they ever make it.

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

Organize Projects into Programs and Reap the Rewards of Change

Posted by Ammar Mango on September 5, 2013

The area of Program Management is still widely misunderstood.  Ironically, it is as old if not older than Project Management.  When the 1950’s pioneers started building Project Management models like the Work Breakdown Structure (WBS), Critical Path Methods (CPM), and Program Evaluation and Review Technique, a program was almost always in mind before the project.

A program aims at achieving a benefit.  So, when a governmental agency undertakes a project to encourage a paperless environment, even if the project is completed successfully, it does not mean that it was able to bring the institution closer to paperless environment.  A project is always about specific deliverables, and by definition is completed when its required deliverables are complete.  So, who will ensure that these deliverables are used, and that they fulfilled the business need for which it was undertaken?  The project is complete, and the Project Manager is on another project.  So who is doing this?

To solve the above problem, some companies are requesting a “support” period during which suppliers are operating the deliverables (whether software, processes, or resources) and ensuring they are bringing in benefits.  This will help, but it is not enough.  Sometimes one project is not enough to achieve benefits.  You need more projects that together will help achieve the goal.  Who will manage and take care of this link?

Another reason to consider a program is that an organization by design is operational, and wants to go back to its day-to-day activities.  This is why many projects fail to change the organization.  They do not take into account getting the organization out of its norms and stability, into embracing the change.  So, when an organizational unit, or executive believes that we need to go paperless, for example, they immediately think of a project to achieve that.  Change usually requires multiple related projects and someone to be accountable to for achieving the benefit, not just delivering a project.  This is why even “successful” projects fail to prove value on the ground.

The answer to this is for executives and organizations to start considering programs and Program Managers to lead the benefit realization, and to spearhead such programs.

I think soon,  the market will be asking for these, and the Program Manager skill will be hot in the market, and many project managers will feel the pressure of having to go beyond their ability to deliver to build a capacity to think strategically and deliver benefits just like a Program Manager would.  These Program Managers will be a potent hybrid of an Executive and a Project Manager, in one person.  I believe this is the Era of the Program Manager.  It should be exciting.



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 »

%d bloggers like this: