Web and software development, IT implementations, and some research programs are the right environments for the Agile “lightweight” approach. In most cases, using Scrum as the most popular framework, the teams deliver better final results for the customer than Waterfall. This is true for internal projects with internal customers.

External customers however, may not be so open to Agile if they only have visibility to a short term Sprint. They will want to have a quote and schedule not for only two or four weeks, but for the entire project. They have budgets to manage and commercial targets to meet, and cannot simply assume the risk of starting a project without total estimates. There is an upfront level of planning that cannot be skipped.

A generic umbrella methology could take good elements from both, Waterfall and Agile, for a hybrid model better suited for sw development projects with external customers.

After all, methodologies and processes are not the goal themselves, but means to help achiving the goals. If Project work is better done with a mix of various tools and techniques from diverse sources, lets do that. Going even further, as sugested by Adaptive Software Development, the team may change the framework during the project, in a continuous learning process, if that is seen as more efective than following a predetermined generic method.

Nevertheless, the organization and teams require some consistency. Team members cannot waste time learning differents ways of working everytime they start a new project. Likewise, Management need some standardized data to plan and measure performance comparatively. The recommendation would be to change and adapt the methodology at first, but then try to stabilize it for some period before introducing significant changes.

A hybrid generic or umbrella methodology can be presented like the traditional waterfall where the planning is somewhat shortenned but still provides the overall level of requirements and design analysis sufficient to create a complete schedule and budget. Development and test cycles increased in number and each shorter in duration, giving more oportunities for user feedback. Prototyping and small functionality deliveries are close to Scrum Sprints.

Plan with Waterfall, Execute with Agile.

To do…
Rfp, sow, contract, total estimation time, cost
Scrum, sprints regular feedbacks, prioritization of features, replacing Change Requests
Avoid cost date overrun, stop at date or cost, 80/20 P0 features done

But many PMs don’t do it. (Based on paper from PMJ Sep 2009; and ad-hoc surveys during PMI 2010 Congress)

It isn’t because the complexity of the mechanics/process, which seems easy enough, well documented as a Knowledge Area in the PMBOK guide: You have a risk register or log, you identify risks, analyse them e.g. for probability and impact, look into responses, remediation or contingency measures, and keep revisiting and updating the register as project moves along…

As usual, the challenge is applying theory to practice.

You think you have done it right, and then some new Risk still hits you because of unknown unknowns (remember Rumsfeld talking of WMD in Irak?), Murphy’s law, “shit happens”, etc.  Sometimes your buffer time and budget will be enough to cover it, other times it won’t…

Examples: The winner of the PMI 2010 Project of the Year, the decade long building of the National Ignition Facility in California, explained during a Dublin PMI Congress presentation that their two main issues were risks they had not considered and were not in their register - The construction site got flooded because of El Niño storms. And sure they were not expecting to find mammoth bones when excavating… Both events consumed money and time, though the project recovered.

Other examples are the typical external (to the project) factors such as weather/Nature (Ash cloud closing Northern European air space; Hurricanes, earthquakes), political changes, economic crisis (Iceland, Greece, Ireland, Portugal), etc…

And this is clear when you realise that the Input to Risk Management Planning, according to PMBOK guide, are “internal” docs, such as Scope Plan, Cost Plan, Schedule Plan, and so on. We can plan for what we know, but isn’t Risk Management too ambitious when trying to control and have a response for the unknown?

Therefore, how much work do we need to put into identifying this very long list of things that may happen? The cost and time needed is a first negative factor. (Sponsors/customers want cheaper and faster)

Then you have the human element of having to talk about Risks…it is all negative and worse-case, it highlights the project or company gaps, our badly prepared areas, our legacy problems…and the PM is the messanger for all those bad news.

No wonder many PMs prefer not doing Risk or doing a “light version” / once off at start. First, as seen, many external factors will be missed -we can’t plan for everything-. Secondly, PMs rather avoid the confrontation with stakeholders and other managers to discuss “potential bad news”.

We need to re-think how we do Risk Management in practice. We need to support PMs to plan appropriately (How Much? 80/20 rule? Set a time and cost limit for Risk Management? Who decides?). Perhaps even a Risk Function should be the owner of this activity for all projects (Portfolio Risk Management – like a mini PMO focused on Risk), where this function has more size and power to get the appropriate cost and time to buffer the project(s).

Matrix type structures seem to be the norm in most project oriented organizations. Companies of different industries such as High tech, IT, Pharmaceuticals, Banking, etc have embraced the benefits of organizing work by projects/programs where resources are picked from various specialised functional lines (Business Analysts, Developers, QA, Legal, etc). Those resources may report directly to their Functional Line Manager, but the Project Manager still holds the responsibility to manage the team and their performance throughout the project/program. 

So, what is People Management and how can we have good performing teams?

I present an overview of People Management by analyzing it at three levels:  The Organization (team context);    The Team (the group);   The Individual (the members, including the leader).

THE ORGANIZATION: TEAM CONTEXT.

• Understand the Organization and the Site that the Team is part of.
• How does the team fit and what role has it got in the Organization?
• How does the team contribute to the strategy delivery and how does it add value?
• The team Vision and team objectives should be clear to all.

There is ALIGNMENT only when the above is well communicated and understood.

THE TEAM: GROUP  STRUCTURE

“A team is a group of people with complementary skills, a common purpose, shared goals, and mutual accountability who share responsibility for accomplishing project or operational goals.”

• Define the structure with roles and responsibilities either when forming a new team or for an established one.
• Understand informal roles such as expert-power positions, SMEs.
• Have a balance of experienced and developing/learning members.

Organize the mix so that it possesses the competencies and capabilities to meet the set team objectives.

THE INDIVIDUAL: TEAM MEMBERS

Each person is different with different motivations: Extrinsic (salary) or Intrinsic (job itself when rich, delegated authority, empowerment)

• Establish expectations with personal goals (SMART) aligned to team/org objectives and for personal skills development.
• Plan against the career path and set a mutually beneficial agreement based on expectations of performance, professional growth and rewards.
• Hold regular One to One meetings.

THE LEADER – MANAGING, DIRECTING, MOTIVATING PEOPLE

• Choosing a Leadership Style: Good leaders can flex styles between autocratic and democratic styles depending on the situation, maturity of the team members and type of decision making.
• Leader should establish direction (from Org strategy and team objectives), and motivate people.
• Building relationships and communications at all levels: inside the team, and from the team to the rest of org and external customers/stakeholders.
• Conflict Management
• Problem solving
• Prioritization
• Negotiation and Influencing

“There weren’t enough hours in a day or a year to spend on people.” (Jack Welsh)

Status reports, or progress reports, are probably the best known document during the life of a project. Other documents such as Business case, Requirements, Architecture, Test Plans, etc are in many cases once off documents that not necessarily all project team sees. Status or Progress reports however, are updated frequently (e.g. weekly) and shared with all the project team, customers and stakeholders. I am using both terms status and progress as synonyms here, as in practice organizations use either when refering to the same document -same purpose. Usually, the report is a one page with both status and progress information.

Don’t bore me, keep it simple and tell me what I need to know. That means Significant and Relevant to the audience. We’re talking of a one-pager, a short document that shows me two things: The Baseline, and any Variations. The baseline is what the project has agreed, the project boundaries in planned scope, cost and time. This should not be too detailed. It includes a summary or the more important deliverables (the scope), the planned budget (and people’s planned hours if not included in the budget), and planned milestones (some key dates from the schedule). Just looking at those few lines and figures, I can get a good idea of what the project is about, and its size/complexity based on budget and hours. This bit should not change during the project –it is the baseline-, that is,  the base against which we will measure if the project does well or not. Variations are deviations to the planned baseline. For example, actual cost higher than budgeted, or not meeting set milestones. We may also have issues or risks that if not already affecting the project, they might in the future. Put that info together and you have a nice Progress report showing planned vs actual data on deliverables, cost and time. The status report section can be done with some text explaining the project phase or stage that we’re in, one line saying what task is ongoing (to give an idea of current position within project life cycle), and a traffic light signal (green, yellow, red) to flag when we think we may face trouble (yellow) or for when we already know we won’t meet the baseline (red).

Improve the report. Add forecasts.  Earned Value and all the forecasted cost and dates are not so complicated. The PMBoK and Wikipedia have good explanations. I think a good status report should always show the Estimated at Completion data to better illustrate any deviations and their estimated final impact.

In summary, a Project Status/Progress Report should show in one page:

1. Life Cycle Phase and one line summary of current activity
2. Flag (Green/Yellow/Red)
3. Main Deliverables
4. Planned budget vs Actual
5. Planned hours vs Actual
6. Milestones vs Actual dates
7. Main Risks and Issues, with impact and actions to resolve

• http://www.insurancenewsalerts.com/project-management-office-pmo-outsourcing-or-a-virtual-pmo-and-project-management-services-outsourcing-a-new-trend
• http://www.pmforum.org/library/papers/2005/PMOCVPWhitePaper.pdf

Outsourcing Pros: No PMO setup time; Best in class tools/ dashboard/ templates; Quality PMs

Outsourcing Cons: Data confidentiality risks (pipeline projects and development plans); Tensions due to having a two tier project teams (external PMs with internal project members)

The key question is: what is it being oursourced/contracted? Is it tactical, methodology/project planning&execution processes,  and PM people (model already popular, loads of PM vendors); or Strategic PMO for Portfolio decision making? I haven’t seen data/examples of this latter case, as the risk of  lossing control of the Portfolio/Strategy seems a serious obstacle. Who is running the company? Portfolio management should always be a core competency of internal Management.

If you are starting or reconfiguring a PMO, think small and focus on some real value deliverable. Ask PMs and senior managers what is their top issue. Is it a set of standard templates? Assistance with planning and scheduling? Need to have visibility of projects progress and deviations? Be clear and specific, agree deliverables with the PMs/management, and commit to deliver something specific (templates, training session, dashbaord tool, etc) in a short timeframe (3 to 6 months max)

Once people see the PMO actually addressing their needs and meeting their commitments, the PMO will be perceived as something of value and worth of further investment. Small incremental steps reduce the risk of failure when implementing PMOs.

In this post I look into a simple model of PMO to support senior management at the strategic level. Strategy support can be understood as the layer over individual projects, comprising the projects but importantly also the decision-making on what projects to start, continue or stop; and priorities. Strategic Project Management is Governance, Program Management, Portfolio Management.

The main PMO tool at this level is the Projects/Portfolio Dashboard. This is a high level view of projects focusing on the details and criteria that is relevant to answer questions such as do I get ROI from this project? or is it aligned to my strategic objectives?

The PMO can faciliate senior management in the translation of business strategic objectives into programs. Programs are a set of projects related in producing a particular outcome. If business strategy is to grow market share then a program may help sales team with faster customer data, quotes, etc. If business strategy is to lower costs, a program may try to simplify supplier chain, etc.

PMO attention is now on monitoring and controlling projects progress and deviations. Dashboards give this high level view grouping of projects in programs or portfolios. PMOs can also assist in project selection and prioritization using a set criteria depending on the strategic objectives (ROI, risk minimization, market share, etc) and the company capabilities (what we know and can do).  Normally we have a mix of projects that represent low risk and we know we can dof (low hanging fruit), plus projects that maximise return or chosen metric.

I think this is a nice simplification of what PMOs can do.

So, let’s see, we are starting to work on projects, or so we think as we have to do some work for customers, we have deadlines and money to spend, but haven’t done project management before… Typical things that we may need are:

• Set up an intranet site or sharepoint site as the repository of PM docs and info
• One page to explain the methodology: e.g. Waterfall model such as Requirements, Design, Build, Test, Release; and Gates Review with Signoff process.
• Standard Templates to document phases’ deliverables (Requirements doc template, Design doc template, etc)
• Standard Templates for Status Reports, Risks and Issues Log, Budget, Project schedule (standard set of milestones)

With all the above we have achieved that all projects will follow a similar plan and development path. Projects will be planned and thought before we start programming or building. The main PM artifacts (budget, schedule, risks&issues, status report) are a minimum that helps the project to be internally controlled, but also allows to compare vs other projects.

A Lite PMO would be responsible to create the site, the docs and templates, and support PMs in following the set methodology. The PMO could be just one experienced PM, not even necesarily at full time.

However, this is a very simple start. Good project management requires more than just templates. The PMO could also support in any other areas where gaps may exist: e.g. Defining project scope/requirements; Getting good estimates;  Ensuring good comms among team members and externally with stakeholders (meeting agendas and minutes), etc

1. What is the starting point? Find out about the context, i.e. Organizational structure and culture; and PM maturity (use any maturity model)
2. What are the expectations? Ask people (PMs, functional managers, execs, etc) what help they need, what are the challenges they face when running projects, what would they like to see changing/improving. Do interviews or surveys.
3. Focus on real needs and balance. Create a plan to design a PMO that focuses on what is has been asked, not what books or theory say. Is it PM training? A resource management tool? Help facilitating risk management? Monitoring project progress? Ensure PMO responsibilities fit with the available tools, skillsets, processes and structure -or adjust for balance. Will the PMO role fit well in the org culture (the way we do things here) and structure (functional, matrix,centralized, decentralized)?

The major reason that PMOs are shortlived or fail is because they don’t fit in the organization’s context, are too ambitious, impose changes that not all people agree with and lack management support. It is key to start focusing on few but true needs -what people see of value to them, e.g some templates, tools, etc-, with realistic objectives and metrics, and show the delivered benefits asap, so  to position the PMO as delivering Value to the company.

People may talk about PMOs based on what they have seen at their company, or some best case example. But each organization is different, and one cannot always re-use the same model in a different environment and context.

But the basics are that organizations want to improve project performance (Truth is that projects generally underperform – late deliverables, cost overrun, don’t meet expectations). If projects by definition are bounded by their particular or unique objectives, scope, resources and timeframe, can they be run as isolated isles of effort, or should projects be coordinated amongst themselves within the same company? How does each project relate to the host organization? How do projects share the common and limited resources in the organization? How do projects and the organization manage conflicts or differences between the projects?

The need for a project management order and understanding, a coordination or standardization of the project management approach within the organization, is what defines the Project Management Office (PMO).