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
    Ammar

  • New!

    PMPNOW Download Link

    Download my new Mobile App PMPNOW! FREE

Posts Tagged ‘PMO’

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.

Advertisements

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

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 »

The PMO and the business model: A continuous interactive loop

Posted by Ammar Mango on June 19, 2014

PMOs are responsible to execute strategy.  But what if the business model is flawed? Most organizations are not ready to deal with this risk.  They always assume the business model is fine, when in many cases it is not.  So what is the role of the PMO in validating the business model assumptions? And how can an organization ensure they are functioning based on value-adding business model that works.  

Strategies are put based on where the organizations want to be in the future and what they want to offer.  However, some strategies prove not feasible, even if executed perfectly.  To demonstrate here are a couple of high level quick examples:

– Company A had a business model that would work perfectly well today, but they had one problem: they implemented the model 20 years ago.  So what they offered 20 years ago would have been perfect today, but not when they offered it back then.  They went bankrupt.  Do not get me wrong; they had a perfect PMO setup.  Their PMO sat on board meetings, ensured projects are proposed evaluated, and selected in alignment with strategy.  Then the PMO ensured the projects were successfully executed.  Unfortunately the whole model was flawed.  It took a marketing executive to come in and give them the bad news.  And by the time they got it, it was too late.

– Company B developed an ingenious software application in the 1980’s.  It was perfect for the mid 90s market.  He was ahead of the market.  

– Some are late for the market.  Company C came in with a different twist on the services it wants to offer.  It looked good on paper, but the customer did not feel their product wad different enough to leave their existing suppliers and work with them.  

All these are examples of flaws in the business model.  Usually, it takes a special kind of expertise to catch such flaws.  It usually is a mix of experience, understanding of the market, and partly luck.  Most of the time, such expertise and capability is not in the PMO.  So, how can a PMO help in ensuring the company has the right business model?  Another pressing issue is how do we ensure our model will work?  The problem is that you cannot be 100% sure.

I have rarely seen a PMO capable of contributing effectively on this issue.  I think the main problem is that most PMOs see themselves as executors, not strategists.  Even when hiring PMOs most companies do not look for a strategist.  They want a doer.  At one point the market will start realizing that we need a doer yes, but we cannot do much without a good business model.

There is good news and bad news in this.  The good news is that in a dynamic environment, a business model can be flawed and then refined.   The important thing is to setup the organization where continuous short loops of feedback are available so we do not invest too much too soon in a wrong business model.  So, organizations need to setup in a way that ensures the business model is always challenged and refined, then reflected in execution. This requires high level of maturity and willingness to change on the part of the executives first as well as the whole organization.  

Even if a company had a good business model for a while, things do change fast in today’s environments.  So, we need a continuous challenge of the way we do business and for that challenge to be encouraged across the organization.  

Setting up such an environment requires executives who have enough confidence and conviction in the importance of change, to allow such changes to take place.  

 

Posted in Uncategorized | Tagged: , , , | 2 Comments »

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 »

A Narcissist Manager’s Guide to the Workplace

Posted by Ammar Mango on October 6, 2013

A Narcissist Manager is someone who believes in nothing but self promotion.  Work comes close second, and people are the lowest on the priority list.  People are almost machines, or better work like machines, as emotions, personal preferences, ambitions, and all such “mushy” stuff are a waste of time, according to the narcissist Manager: “Get the job done, or else.”

The narcissist manager mentality is on the rise.  Yes, it is sad indeed.  However, one can easily be amused by the way of thinking of these managers, as it is amazingly simplified into its core beliefs: No one to be trusted, everyone is selfish, people should be intimidated into work, and yes the most important of all: your employees must fear you so they work properly.

I have met a few of these managers throughout my career.   They are so similar to an astonishing point.   If I was to put their behavior in a user manual, this is what it would look like.  Please note that I do NOT condone this behavior and I definitely discourage it and do not appreciate it.  However, just for fun and also learning what NOT to do, here is the quick guide:

1. Fire anyone you do not like, as soon as they cannot hurt you.  If they cannot be replaced, be nice to them until you can ditch them.

2. How to deal with those who say no, disagree with you, or hint at mistakes you made or are making? Preferably fire them.  If you cannot, then scare them and intimidate them into submission, if you cannot, or they are too strong, be nice to them, make them think you like them, then when the moment is right, make your move and fire them.

3. Sick people, or those you expect to be sick for a while: You guessed it; Fire them, but cover yourself legally, so you do not get sued.  Make up some accusations about their incompetence, mistakes, or anything else so no one knows the real reason you fired them.

4. Family members, friends, friends of friends, or people you need to kiss up to: Hire them.  You cannot have enough of these people.  Actually hire those who talk like you, dress like you, or say they like you.  Why not even hire those who look like you.  That is even better.  Nothing better than seeing good looking people to make one feel good about self.

5. Gossip, lying, manipulating, backstabbing, and hypocrisy, are the tools of the trade, when it comes to business. Encourage them among employees (as long as they are not directed at you) and learn to use them wisely.

6. Truth, honesty, loyalty, friendship, are all words used to manipulate others to believe you and do as you wish.  All are safe tools to use as long as you never really believe or “fall” for them.

7.  Never admit a mistake.  Blame it on someone else, or pretend it was not a mistake to start with.

8. Put down others’ work, then at the right moment put it in a different format and claim it is yours.

9.  When in a team, do the least work, and most of the talking.  Feel free to claim team victory as yours.  It is yours after all: you are the inspired boss.

10.  Attack competitors, peers, and everyone else in your business network, but in a subtle way.  This will keep you shining and above everybody else.

11. When everything fails, blame someone, the weather, the whole team, government, economic conditions, but never assume you had anything to do with it.

12. Emotions, empathy, and feeling for others are for the weak.  This is why you win, and you are superior, because you do not let such foolishness get in your way.

13. If you end up alone and hated, it is only because you are so successful, and beautiful too.  This has got to raise the level of envy of others.  So, consider it a compliment that you have no friends.

14. Some people in your organization stay for a very long time.  These are the keepers.  They figured out how to work with you.  They never leave, they have no ambition, they are willing to keep doing what they are doing for you.  These are the kind of people you need around you.  Welcome hem, keep them, and reward them.

15.  Some people, troublemakers, want to do things differently, have their own ideas, and other blasphemous behavior.  These leave your organization quickly, either fired or run away.  The sooner the better.  Good riddance.

Posted in Understanding OTHERS | 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 »

The Project Stakeholders; The role vs The Person

Posted by Ammar Mango on August 30, 2013

Image

Some prefer to look “objectively” at projects that they focus on the roles people play rather than the persons behind the role.  The rationale is that by focusing on the role, they stay objective and do not let personal matters play a role in their judgment or interactions.  While on the surface this looks great, based on what we were taught about not to take business personally.  In reality, there are aspects of business that require a “look” at the personal aspect of the people we are dealing with, and for others to also see us personally.  While objectivity is needed and role accountability is key, it is naive and harmful to blind ourselves from the persons we are working with, as persons.

There is confusion out there between how “not to take things personally,” versus understanding and employing the personal elements to improve chances of project success.  In reality, both are needed and both can be applied on a project, and neither is in conflict with the other.

Being objective means that I have to hold people accountable for their roles, regardless of personal preferences or prejudice.  If a friend on my project team messes up, he is as accountable and a non friend or someone I might personally not like.  This is always true and holds as a rule, and as an example of how not to take things personally.   Another example is when dealing with project problems and taking responsibility for our “role” in the conflict or in the problems or mistakes occurring in the project.

Addressing personal aspects come into play still, without having to compromise on the objectivity factor.  For example, for the under performer in the above example, his personal preferences and our personal understandings might be a motivation for him or her to get over the challenges.  For example, his communication preference, his attitude, his likes and dislikes, his background, his culture, all these factors create the person, and I can use all or any of these to get what is needed from this person, whether better performance or just better understanding or empathy.  I remember once I worked with a perfectionist architect who used to accept or reject project work on the most minuscule ( and some might say ridiculous) things.  I remember during walk-throughs on construction projects, he used to look at the natural wood grain in closet doors, to ensure that both sides of closet doors have patterns that, when the doors are closed, the seem in between does not show.  I mean talk about anal.  However, Respecting, instead of fighting this difficult personal attitude resulted in a mutual respect relationship between the architect and the project manager, that helped the architect see how the project manager is trying hard to accommodate the sometimes difficult requests of the architect, and be tolerant when the requests cannot be met, or when the project manager objects to the tough requirements.  this is personal relationships working for mutual benefit and project success.  this did not negate objectivity, it supplemented it with the reality of, let’s face it, we are after all humans.

As far as the picture, it is just a play on words.  Just for fun “Steak” Holders 🙂 me and my sense of humour

Posted in Uncategorized, Understanding OTHERS | Tagged: , , , | 1 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 does Innovation have to do with project management?

Posted by Ammar Mango on August 22, 2013

A lot, and definitely more than meets the eyes of some project managers, who see their role as delivering the project per specs.

Innovation is at the core of every project.  By definition, a project is undertaken to create a “unique” outcome.  Unique means never ever done before and will never be repeated throughout history.  Whenever we are talking about unique, we have to talk about innovation.

When a company undertakes a project, it is because the normal daily operations cannot produce the outcome desired without project intervention.  So, the project intervention has to find innovative ways to fulfill the business outcomes required, by ensuring the project is completed successfully and handed over properly to business.  Projects are about change.  Change results in something new, and without innovation there is nothing new.  

Some think of innovation as breakthrough innovation and that is not accurate.  While breakthrough innovation is part of innovation, it is not the only part.  Many innovation comes gradually and never reaches breakthrough point immediately.  It sometimes takes multiple projects or even programs to create a substantial change in a product, service or outcome.  Most innovation is about finding ways to improve in everything we do.  So, innovation is about improvements even if small, until we reach substantial improvements.

Some think innovation is about ideas.  Again, partly true.  Ideas on paper are just ideas.  The more important aspect of innovation is finding way to execute successfully these ideas.  

Seasoned project managers understand the importance of innovation for the success of their projects.  They look at projects as a chance to go beyond the ordinary and expected, and find better ways to deliver.

Here are a few things you can do to encourage innovation at the project level:

1. Start with a big picture of what the project is, and then ask “how can we improve on previous performance?”

2. Look at new ideas and opportunities that will improve on the product or service 

3. Make it part of your process to pull the PM and technical and business experts before initiation of project to discuss points 1 and 2

4.  Make a rule of “one improvement per project” for all new projects in your portfolio

5. Look at your solutions and services from the user perspective and find new ways to provide value

6. Relentlessly critique current ways of delivering projects and look for chances to improve

7. Collaborate with technical teams and consultants on improvements.  These can be casual discussions with others on how to improve 

8. Stay abreast of the latest research, technology, innovations OUTSIDE your industry.  A lot of innovations and improvements are business related and can be applied across industries.  Do not be stuck in your industry when searching for innovation.

9. Make your focus the business need, not technical features when looking at IT solutions and improvements

10. Be a leader, not a follower; do not accept answers like “everybody does it that way,” or ” this is not doable.” Most of the time everybody does it that way because they do not take the time to think of a better way.  Some things are not doable but most of the time this statement is used as an excuse for complacency.

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

Pick A Consultant; Not Just Any Consultant!

Posted by Ammar Mango on August 7, 2013

pickaconsultantThere is more to consulting than just the consultant.  There has to be.  This is why the same consultant might do a splendid job for one organization and not so well for another.  Consulting is about the client, culture, and timing, as much as it is about the consultant.

Consultants vary in style and personality and that variation makes our experiences with the same consultant so different.  You might like him, I might hate him.  Actually, I might love a consultant on one day and hate him on another.  When hiring a consultant pay attention to their personal style as it will affect your ability to get the benefits you are seeking.

For example, some consultants are so non-committal style that they tell you everything is possible, and they would be right too.  For example, when asked if this approach might work, they will tell you it might, even if it had a chance of 1 in a 1000.  They are so concise that they might spook the untrained eye.  Some clients are comfortable with such consultants.  They can deal with the extra preciseness.  Others might not.

Some clients would shy away from the “non-committal” style consultant, and want an “Assuming” consultant.   Assuming consultants are the ones willing to take responsibility for decisions on behalf of the client.  For example, they are comfortable telling the client what to do and what not to do, or what would work and would not.  they would say it with almost certainty as they consider 90% confidence is good enough for them to dismiss the possibility of failure.  For example, they would tell the client, if you change this approach, you will get better results guaranteed.  Of course the consultant cannot guarantee the results, but he is trying to help the client take a decision.

Everyone has experiences with both types of consultants.  Personally, I remember once I was looking to buy a house in Michigan in the early 90’s.  I got introduced to an excellent Realtor who is a friend of a friend.  He took me through quite a few beautiful houses that fit my needs perfectly.  He never was bias.  When I asked him his opinion, he would objectively state the pros and cons of every house, but never pushed me to buy any.  the result of this non-committal approach was me not buying anything.  Not because I did not find anything I like, but because I needed a bit more help given my low level of experience with the market at that time in Michigan.  Five years later, he would have been the perfect Realtor to help me pick a house.  but at that early stage of maturity in my knowledge in the housing market I needed someone more aggressive, who would put his neck out, beyond his duty as a consultant, to “sell” me on a good idea or, in this case, a good house.

I have to admit that I have fallen in this trap with clients all too often; where my diligence in being an “honest” consultant, kept me in the non committal zone, with clients who needed a little bit extra help.  The result was confusion and frustration from the client.  With mature clients who understand fully my role as a consultant, and there responsibilities as clients, the approach worked perfectly for both sides.

There has to be an honorable mention of the “Zealot” consultant.    This is the consultant who is taking things too personally to be objective at all.  He would even take it personally if you do not follow his or her recommendations to the letter.  Even this type of consultant is needed also for some clients.  When the client lacks the discipline but wholeheartedly wants the results, then the zealot consultant is a good solution.  The zealot consultant is a hat that you were and it is not a personality necessarily, even though I have to admit some zealot consultants have this hat on even when they sleep.  They are zealots to the bone.  However, it is OK to act like the zealot consultant when your client is asking you to help them with discipline issues, not only structure or process.  A word of caution though: sometimes we wear the zealot hat when we are too attached to the client or the account.  For example, if you are somehow attached to the mission of the organization you are helping, then you might find yourself too critical and judgmental whenever they make a mistake.  You might even be pushy in getting them to do what they should do, and you might even get angry and lose composure when the client is not listening or not following agreed upon actions.  This is why a consulting company needs consultants to help them improve their own operation; internal consultants, no matter how experienced, are too attached and emotionally involved to objectively deal with the challenge.

So, when choosing a consultant, take into consideration your style, organizational culture, and the issue at hand, and see if their personality meets the specifics of your situation.

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

 
%d bloggers like this: