Project Management Methodology

Projects are like a box of chocolates

How many of us remember the famous quote from Forrest Gump, “Life is like a box of chocolates. You never know what you’re gonna get.”? Being assigned a project is a little like that box of chocolates – you never know what you are getting until you take that first bite. A project is like taking that first bite of chocolate – unique, but having enough similarities to fit inside the chocolate box.

  • How do you determine the best methodology when you start a project?
  • Do you have a PMO that dictates the methodology?
  • Are you in a company that has adopted Agile as its methodology?
  • Are you using Waterfall?
  • Or, as the project manager, do you have the authority to determine the best methodology for the project based on its assigned team, scope, timeline and cost?

Like that box of chocolates, each project might be unique, but it still needs to work within an agreed upon methodology that is flexible enough to support small to large, complex projects. If the methodology cannot handle the flexibility, it needs to be re-evaluated to support all project types within the organization.

Create a project methodology that supports all project types by defining the critical project artifacts for each project type (e.g., small, medium, large). At the end of the project, perform an analysis of the project and determine what worked \ did not work, and adjust the project artifacts to suit the project.

How?

  1. Determine the methodology framework – Agile, Waterfall, WaterScrumFall (blend of Agile & Waterfall).
  2. Define what artifacts are needed for each project type – then map the processes using a tool such as Visio and share the process with others.
  3. Projects are more than producing documentation because that is what the PMO dictates – involve and evolve your PMO to a strategic partner.
  4. Provide feedback to continuously improve the process.

Projects are like those chocolates. We can savor each project’s unique flavor and make each a success if we follow a standardized approach that can also flex to support the uniqueness of each project. The approach should be like the chocolate box, able to accommodate each unique shape within a larger, coherent framework. Our job is to understand the uniqueness of the chocolate while appreciate the box in which it sits.

homer_simpson_doh_02

Does your PMO get in the way of your Agile Development Teams?

Do your agile teams have your PMO pulling their collective hair out in frustration?

A family in harmony will prosper in everything. ~ Chinese Proverb

Does this sound familiar:

We value face-to-face conversation We need formal, written documents
Working software is our primary measure of progress Where is your status report?
How are you progressing against your project plan?
Self-Organizing Teams Defined Roles and Responsibilities
Individuals and Interactions Processes and Tools
Respond to Change Follow a Plan
Culture of Change Culture of Order

You’ve embraced an agile development methodology, empowered your teams, and they are eager to move forward.  They want to deliver a quality product to the organization as quickly as possible.  They want to add value and make a difference.

Your project management office (PMO) understands and supports the agile development approach, but they still need to manage the overall project portfolio and they want to be sure that the agile teams deliver in alignment with the organization’s strategic objectives.  They want to add value and make a difference.

Both groups have the organization’s best interests in mind, but there is a definite culture clash.

Agile teams can be dismissive of the PMO. Their approach is different, they don’t need to worry about those processes and frameworks; they just need to focus on their own project.  The PMO should get out of their way.  It reminds me of a teenager who wants their parents to just leave them alone – until the parent is needed.

PMOs can act like a dictatorial parent.  They can demand process and procedure from agile teams because that is what they’ve always done.  But process and procedure that doesn’t add value does get in the way.

Both groups need to respect each other and adapt.

Just like the parent of a teenager, the PMO should be loosening the rules and allowing greater freedom while demanding accountability (and standing by with a safety net). The PMO has to adapt itself to the agile world,  working with the agile teams to understand the tools that they are using to manage and control the agile project.  It should adapt these tools to their use rather than making the agile team use the same old PMO provided reports and templates.

The agile team, like the teenager, also needs to acknowledge and respect the role of the PMO.  The project and the project team aren’t operating in a vacuum.  It needs to fit into the larger organizational plan and processes.  So the agile team needs to fit itself into the framework that the PMO has established.  That may mean complying with certain project checkpoints or processes, such as conducting a formal risk analysis or establishing a milestone-level, project plan, budget, and scope.

If each can recognize that the other is not purposely trying to obstruct them and understand the value of the other to the organization, they should be able to leverage on another’s strengths.  While there may still be friction and areas of disagreement, the end result should be a set of processes that improve project outcomes and ensure alignment with overall organizational objectives.

Project Triage During Rapid Business Change Cycles

A few years ago, we ran a series of blog posts on project triage, diagnosis and rescue:

How often do you perform project triage?triage

Preparing for Project Rescue: Diagnosis

Restoring Projects to Peak Performance

In much of our work since then, we have been working with organizations that struggle with performing meaningful project interventions to align their project portfolio with sudden shifts in business strategy, or to support their underlying corporate culture as it shifts toward more rapid innovation, originality, adaptability, engagement, collaboration and efficacy.

In such fluid business environments, our original medical metaphor doesn’t fully apply; triage and diagnosis were performed from a perspective of project internals.  In today’s world, the old project success indicators can be very much out of sync with the business.  If IT projects, the project portfolio, and a PMO are not accountable in terms of their value to the business, it’s time to change the ways we think and talk about projects, and begin to define new KPI’s for success.

  • First of all, let’s stop using the term scope creep.  To deliver business value, the project organization must be agile enough to rapidly address scope fluidity. Would it make more sense to measure how quickly a project team can replan/re-estimate a shift in scope?
  • Quality metrics may also need to fall by the wayside. Is the current release good enough to push into production with defects noted, and expectations managed–think of the release as a minimum viable product, like lean startups do?
  • In rapidly changing businesses, it’s very difficult to plan out a 12 month milestone plan for IT projects. It makes more sense to define a backlog of objectives at the beginning of the planning phase, and perform rolling prioritization, with the complete expectation that the prioritization will change at multiple points during the coming year. In such an environment, how meaningful is it to judge project success against the old notion of “on time”?

In the context of all of this change, it is no longer reasonable to judge projects based on their internal conditions. The measures of project success in today’s world lie in the greater business context.

  • Has the project or project portfolio enabled the business to respond to threats and opportunities more rapidly?
  • Has it increased our innovation speed?
  • Even if the application is buggy, has it improved overall efficiency, enhanced the quality of goods and services, reduced operating costs, or improved the business’ relationship to its customers?

While these questions have answers that are less quantifiable, they are certainly more meaningful in today’s business context. How is your business evaluating project success these days?

Will you be able to see the Black Swan?

Pity this poor project manager. He never saw the black swan coming.

Couldn’t see it through his magic green colored glasses.

However, projects do not suddenly overrun their budgets by 200% without any warning signs along the way. The following project managment traits are among those that are likely to lead to the epic project failures known as black swans.

  • Logging more new issues than we are closing every week, but the status is still green.
  • Never challenging task owners who keep saying they will have it next week, let’s just slip the due date and keep the status green.
  • Calling the strategy tasks done so we can start logging some effort as complete against all these development tasks, so we can still say we are status green, and % complete is aligned to % budget consumed.
  • Let’s get a conditional signoff on the requirements doc so we can start development as planned on Monday, and stay status green.
  • We’re running out of budget so let’s not provide any training materials, and just give the users a walk through, so we can keep the budget status green.
  • We have a few process workarounds to define, but let’s go live as planned so we can keep the status green.
  • Key stakeholders are unavailable, but let’s change the design anyway so we can stay on schedule and keep the status green. 
  • We’re burning the midnight oil cranking out code, and we need input on a design workaround, but no one is available, so let’s make a unilateral decision so we can keep on schedule and keep the status green. 

While its true that sometimes heroic effort can keep a project on track, it usually takes more than optimism. The true mark of good project management is not  keeping status green in the face of evidence to the contrary, but early identification and escalation of risks so that the executive sponsors and steering committee can make adjustments to scope, budget and timeline in a way that facilitates the path to success.

Carving out a new company, aka “Just Add Water”

Earlier this month, our Google Alerts picked up a press release praising our role in a recent carve-out project. It was a nice surprise for us, and has generated some inquiries about our role. In this post, I’ll quickly scope out the project, and our role, for you.

Edgewater Technology was approached by one of our existing clients to assist with defining technology strategy for a “carve-out” that they were bidding on. Both parties sought a way to minimize or eliminate the need for a transition services agreement (TSA) and close the deal as quickly as possible. Our client, the buyer, intended to integrate the carve-out into one of their existing portfolio companies. This portfolio company was running well with a lean organizational model and homegrown ERP platform, but it was clear that it could not absorb the new acquisition with its existing enterprise technology architecture. Senior consultants from Edgewater Technology’s M&A and Infrastructure Services practices, with our colleagues from Edgewater Fullscope, our sister company with expertise in implementing Microsoft Dynamics AX, quickly put together a strategy based on:

  • Migration of the acquisition onto Microsoft Dynamics AX
  • A new corporate network  to link the parent company with 1 US and two international sites, providing for remote access for employees and contractors as well
  • Hosted MS Exchange based email
  • Hosted MS Sharepoint
  • Virtualized application deployment in Edgewater’s Data Center

In addition to implementing the technologies described above, Edgewater rehosted a smaller ERP system in use at one of the international sites, to avoid having to take on two ERP application migrations at once. This business unit will eventually migrate onto AX after the initial  stabilization of the US business is completed.

Because of Edgewater’s 10+ years of experience with M&A integration, program management, business process definition and organizational change management, our team provided these wraparound services as well, spearheading a Program Management Office that embraced all US and International acquisition sites and members of both the Buyer’s and Seller’s transition teams.

In an intense 120 day transition, Edgewater successfully completed the implementation of all the technology described above, as well as definition of key business processes for a global organization that relies on international suppliers and domestic third party logistics providers.  Some of the challenges we addressed along the way included: 

  • Bringing up a short-term web-based EDI solution to meet the aggressive timeline, while beginning to rollout integrated EDI processing in time for Day 1
  • Reconciling numerous issues data migration issues
  • Replanning exercises to address unforeseen obstacles without jeopardizing the timeline
  • Scaling down our implementation methodology to minimize the resource requirements on a lean core team that was still running the platform company’s business with no backfill
  • Training a workforce that included a significant number of new hires

2010 New Year’s Resolutions: Project Management/PMO

Along with the holiday festivities, the last half of December turns everyone’s thoughts to New Year’s Resolutions. If you adopted any of our project management resolution suggestions from last year, please leave a comment and let us know how that worked out for you. And, if you haven’t taken our survey about project success, please do. It will take you only 5 minutes, and we’re looking for both IT and business perspectives.

For 2010, we’re expanding the scope of our resolutions to include a few PMO resolutions as well. (Don’t worry, we’ve filed a change control request and had it approved by the proper authorities!) We approached 2009’s resolutions with an eye toward cost reduction, based on a grim IT budget outlook. 2010 looks like it will not see further cuts, with most companies either keeping budgets in line with prior year, or boosting IT spending by a modest 4-6%.

In this budget context, it’s still wise to consider ways to work smarter, not harder, and tighten up the alignment of all of your projects with the overall strategy of the business, realizing that the strategy often changes over time.

So, without further ado, here are our 2010 Project Management/PMO resolutions:

1. Writing up your meeting minutes is not as critical as limiting the minutes your team spends in meetings. Don’t get me wrong: published meeting notes are important, and they should still be distributed within 24 hours of each working meeting.  The following mental exercise will bring home the importance of running tight, efficient meetings:

1. Count the number of meeting attendees.

2. Multiply by the length of the meeting in hours.

3. Multiply by the number of meeting occurrences over the project lifespan.

4. Multiply by a fully burdened hourly rate.

A weekly internal status meeting for a year-long project could be adding significant cost to your project. Limit your agenda to the essentials: It’s not so important to review what everyone has done or what went well. Use the meeting time for resolving issues and managing exceptions.

2. Revisit the charter for your PMO and make sure it serves the business, and does not ask the business to serve the PMO. PMOs that exist to enforce consistency and police compliance with a methodology often end up slowing down project execution instead of enabling project success. Standardize project plan templates at the highest level necessary for tracking milestones across projects, and let individual project managers develop work breakdown structures within that framework, to a level that suits the needs of individual projects.

3. Develop a less adversarial attitude toward change. Much is written about scope creep and change control in project management circles. There may be a tendency to take too hard a line toward change. The reality is that business conditions, needs, and strategy may well change over the lifespan of many projects.

Let’s move our definition of project success away from the old metrics of “on time and within budget” toward more realistic measures of business success. Some more appropriate ways to judge success of a project include:

  • Did the project fulfill the objectives, as defined in the original project charter (if you don’t do project charters or business cases, add that to thei list of resolutions) and all subsequent change requests?
  • Are end-users satisfied that their requirements have been implemented, and can they easily perform their daily tasks using the new system?
  • Some metrics are specific to the type of project, such as:
    • For business intelligence projects: Has this project enabled the business to make better and quicker business decisions by putting better data and drilldown capability into their hands?
    • For projects that install new transactional systems: Have we improved overall efficiency and accuracy of critical business transactions?

4. Develop an efficient framework for project triage. Not every project needs the same level of support. Some projects need to be suspended or rescoped as business needs change. Regular project triage is a best practice that helps organizations make sure they are keeping IT budgets aligned with business needs. Make a commitment to quarterly triage in 2010. Incidentally, if you haven’t taken our project triage survey, we would value your input in this area.

5. Re-order the priorities of your project managers. Make sure that they understand that their most important responsibility is maintaining a healthy working relationship with the business. Tracking status, updating the plan, and managing the tech team are not the key enablers of project success.  The most valuable skills to strengthen in your PM staff  are related to communication, conflict resolution, consensus building, and salesmanship (they will often have to “sell” reluctant stakeholders on compromise solutions).

New Year’s resolutions are really just an attempt to institutionalize a project management best practice that should become standard operating procedure throughout the year: periodically re-examine your approach and commit to continuous improvement efforts. That’s the real secret to successfully building a high-performance project management office within your organization.

Reshaping your PMO to Beat the Recession

There’s been some buzz lately on how PMOs can help your company spend wisely during a recession. In wading through the recent buzz, it’s important to know that not all PMOs are created equal, and the skills of the PMO leadership can make or break your ability to use a PMO as a weapon in your recession-beating strategy. Because the economic climate has changed drastically, you may be in danger of overspending if you don’t re-evaluate and re-engineer your PMO to meet the needs of the day.

Kristen Caretta, at Search CIO-Midmarket discusses how project management offices are uniquely positioned to cut projects that have spiraled out of control and identify those critical to meeting changing business needs and increasing business efficiency.

An article at CIO.com includes key metrics for gauging PMO success. It’s important to reconsider your metrics during the recession, however, because the shift in business climate may require you to track against different targets.

Look critically at your PMO and the way it operates to see if your organization is guilty of any of these behaviors. All of them can actually cause a drag on your bottom line.

  • Undue effort spent on policing project teams fpolice-monkeyor adherence to a standard methodology. A highly functioning PMO evaluates requests for exceptions to methodology standards and helps the teams run with a lean and mean approach that speeds up progress while imposing an identifiable and acceptable level of risk to the business.
  • Hyperfocus on metrics. Don’t let the endless trackinbusiness-chimpg of metrics become an end unto itself. The only thing that needs to be reported and addressed are the exceptions-those projects that are riding off the rails. It’s a waste of corporate resources to publish lengthy status updates on projects that are humming along without any problems.
  • The half-day weekly PMO meeting withmeeting-monkeys a cast of thousands. Be very clear on the purpose of your regular PMO meetings. Using them to resolve cross-cutting issues and refine project strategy or reprioritize the project portfolio and realign resources is a good use of time. Dragging every project manager through status updates for each project only makes sense if the projects are somehow inter-related.
  • The IT PMO-in-a-silo. The biggest bang for ymonkeysour PMO dollar is in its ability to foster alignment between business needs (which may in fact change over the lifespan of a project) and implementation projects. You can only do this if your PMO is an enterprise (as opposed to an IT) entity. The director of your PMO needs to have a solid record of experience in advising and negotiating at the C-level, in addition to rock-solid project and program management skills.

To navigate the recession, don’t assume that your current PMO is already providing exactly what you need to win in a difficult economy. If you don’t have a formal continuous improvement approach in place, a semi-annual review and realignment of PMO approach and operations may be in order.