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.

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