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?

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?

Why a PMO

Project Management Office

The words make some shudder.  Of course PMOs have existed for a long time.  They grew as the discipline of project management itself matured and people recognized that project management was a distinct skill set that demanded training and experience, as well as certain natural talents.

While PMOs are often associated with larger firms which need to establish a standard methodology and approach for initiating, managing, and controlling systems-related projects, there are many reasons why a company might consider establishing a PMO.

First, a PMO does not need to be focused on systems-related projects.  The real benefit of a PMO is its ability to bring a disciplined approach to how an organization approaches projects.  Any time an organization is contemplating a series of projects to introduce transformational change, a PMO can improve the odds of success.  Those projects can be systems focused, but they could also be focused on business process redesign, new product development, geographical expansion, acquisition, or reorganization.  Each organization can decide for itself what type of projects should fall under the auspices of a PMO.

Similarly, a PMO does not need to be focused on all aspects of project management – at least in its initial implementation.  A PMO should address existing organizational problems.  If the organization struggles with prioritizing project requests and deciding which projects to fund and staff, the PMO should be focused on this issue.  If the organization struggles with keeping projects on track and resolving issues during project execution, the PMO should be focused on this issue.  Simply implementing a PMO doesn’t bring value to an organization.  Implementing a PMO so that it addresses the real-world issues that the organization is facing does bring value.

While PMOs take many shapes and flavors, they all seek to improve communication, collaboration, and consistency.  Organizations face increasingly complex environments while striving to respond to customer demands.  They often rely on a set of projects to drive the organization towards a new strategic vision of itself.  These organizations can leverage a PMO to more effectively meet these commitments.

So why consider a PMO?  If your organization is facing substantive change and needs to improve its ability to consistently and successfully deliver projects so that it can implement that change, a PMO can help.

How do you know when the gap is too big to jump?

Ever watched a motorcycle jump?  Ever wonder how guys like Evel Knievel knew how far they could go? How fast they could make the jump?  How to tune that motorcycle so it would support repeated efforts to break and rebreak records?  Was the cycle the secret to success or was it more a matter of mind over matter, training and instinct?

Many businesses face the same challenges as they try to accelerate the pace of change, embarking on transformation initiatives that often demand that their people bridge frighteningly huge current-to-target state gaps. The price of failure is as catastrophic to a business as those motorcycle jumps are to the daredevils who attempt them.

Is technology the secret to success? Methodology? Only partly so — Objective measures of the size of the gap (a catalog of differences between the current and target states of process, technology, data, and business model) will only get you so far. Project phases can be designed to address this, and the classic stuff of project management can certainly help. I call this the hard science side of the equation.

However, for both the intrepid cyclist and the daring leader of an audacious business transformation, success is both an art and a science.  Just as a jumper has to factor in the strength of crosswinds, the nuances of posture and the internal state of mind, transformation leaders need to address the following questions, which speak to the art of success:

• Does your organization have a framework in place to foster change (communication, collaboration tools; a training framework)
• Is there a formal framework for facilitating alignment among stakeholders with different needs?
• What is the state of employee engagement at your company? Who is burned out, checked out, counting down the clock to retirement? And who is revved up and raring to go?
• Are there wounded bodies still littering the canyon from your last attempt to jump a big gap?
• Do you have realistic expectations of the business input required to support a technology-driven transformation? Do you have a backfill strategy?
• Have you defined success in business terms, or are you just eager to “put in a new system?”

When considering anything unprecedented or record breaking, don’t put all your faith in science—and don’t devalue the many human factors that are very much a part of the art of success.

A More Agile Approach to Project Management for 2013

It’s been a while since we’ve done an annual wish list for project management, and while we are a few days into the new work year, it’s not too late to think about some PM rules to live by for 2013.

Fluidity is key; rigidity can stifle project progress. Traditional frameworks call for a priori definitions of roles and responsibilities. In many highly successful organizations, models have been shifting toward more collaborative structures. Efficient teams are being built of all-rounders instead of silo’ed specialists. Such a staffing model provides more opportunity for agile workload balancing over the lifecycle of a project, and may enhance the team’s ability to bring the project in on time.

Managing your stakeholders expectations is more important than managing your project team. Let’s assume you have a skilled team and a well written project plan. Should you be spending most of your time micromanaging and tracking the status of their every move, or would you add more value by communicating more often and more directly with your stakeholders? Let’s stop considering communication a “soft skill” and recognize it as a key enabler of project success.

Change is not a necessary evil. Typically, the project management framework views change requests or change control as a negative, but the level of agility required for most businesses to survive make changes in scope a GOOD thing from a business perspective. Classic project management provides a framework for executing scope changes, and good project managers embrace the change requests, calmly, cordially, and without an attitude of tension or disdain.

Collaboration tools are no substitute for interpersonal interactions with your team or stakeholders. Email alerts, project portals, tablet apps that give visibility into project status are all great tools. but sometimes the best way to stay on top of progress is still to walk around with your issues and tasks lists, cruising by cubes and offices to get status updates in the context of informal conversations. The upside is it allows you to keep a finger on the pulse of the people who are important to your project, and it promotes better engagement. A phone call to remote team members is always appreciated. This is especially important with key executives. Firing off email requests for status is not the hallmark of a good PM.

Less is more. Lean thinking is everywhere these days (and I’m not talking about post holiday diets here). In the entrepreneurial community it’s all about minimum viable product. Agile methodology has pushed projects in the lead direction, with each iteration being a minimum viable release of sorts. In 2013, let’s think about minimal project structure. Rather than adding to a methodology, think more about what we can strip away to do it better, faster, cheaper.

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.

No one likes plain vanilla anymore

More and more businesses are seeing the sense of trying to adhere to “plain vanilla” implementations of packaged software applications, without customization to the application code. It’s cheaper on the implementation side, and certainly cheaper to upgrade uncustomized package applications.

This guiding principle is often articulated in the kickoff slides, and all the key stakeholders and executive sponsors nod in agreement.

Here’s what usually happens next.

Analysis begins. Implementation team business analysts work with designated subject matter experts (SMEs) to gather the business requirements that will be used to configure the application.  They are adamant that their job must be performed exactly as it is performed right now. The SMEs are like ravenous foodies, seeking to outdo each other with requests for  ever more exotic ice cream flavors of the day, while your plain vanilla implementation is melting away, because no one really likes plain vanilla anymore.

How can you get this under control?  Intervene early and police ruthlessly during the analysis phase. Add the following expectation-setting statements to your kick-off slides, right after you articulate your plain vanilla guiding principle:

1.  All customization requests must be reviewed and approved by the steering committee.
2. Potential process workarounds will be explored before any customization requests can be approved.
3. There may be more business process changes than there are customizations to this application.
4. We will provide training on both new business processes and new procedures for working with the new software.

Statement 4 becomes a difficulty if you have not assigned responsibility or budgeted for the effort involved in documenting new business processes, and building and delivering the process training. This is typically not part of the scope of the software implementation vendor’s responsibility.

To prepare for adherence to the full set of guiding principles, you need to develop internal business process/change management capability, or budget  for outside help in support of any major system implementation. Failure to do so puts the success of your software implementation project at significant risk.

Last piece of advice: at your go-live party, serve two flavors of ice cream.

Plain vanilla for the team(s) who favored the process workaround route. If they were really good, give them a choice of toppings. For the others, give them exactly what they craved. They’ll fall into line on the next implementation.

Keeping the Black Swan at Bay

A recent article in the Harvard Business Review highlighted some alarming statistics on project failures. IT projects were overrunning their budgets by an average of 27%, but the real shocker was that one in six of these projects was over by 200% on average. They dubbed these epic failures the “black swans” of the project portfolio.

The article ends with some excellent advice on avoiding the black swan phenomenon, but the recommendations focus on two areas:

• Assessments of the ability of the business to take a big hit
• Sound project management practices such as breaking big projects down into smaller chunks, developing contingency plans, and embracing reference class forecasting.

We would like to add to this list a set of “big project readiness” tasks that offer additional prevention of your next big IT project becoming a black swan.

Project Management Readiness: If you don’t have seasoned PMs with successful big project experience on your team, you need to fill that staffing gap either permanently or with contract help for the big project. Yes, you need an internal PM even if the software vendor has their own PM.

Data Readiness:  Address your data quality issues now, and establish data ownership and data governance before you undertake the big project.

Process/organization/change management readiness: Are your current business processes well documented? Is the process scope of the big project defined correctly? Are process owners clearly identified?  Do you have the skills and framework for defining how the software may change your business processes, organization structure and headcounts? If not, you run a significant risk of failing to achieve anticipated ROI for this project. Do you have a robust corporate communication framework? Do you have the resources, skills and experience to develop and run training programs in house?

Let’s face it: experience matters. If you’re already struggling to recover from a technology black swan, you are at considerable risk for reproducing the same level of failure if you don’t undertake a radical overhaul of your approach by identifying and addressing every significant weakness in the areas noted above.

We have developed a project readiness assessment model that can help you understand your risks and develop an action plan for addressing them before you undertake anything as mission critical as an ERP replacement, CRM implementation,  legacy modernization or other mission critical technology project. If you have a big project on your radar (or already underway), contact makewaves@edgewater.com to schedule a pre-implementation readiness assessment.

Paying Too Much for Custom Application Implementation

Face it. Even if you have a team of entry-level coders implementing custom application software, you’re probably still paying too much.

Here’s what I mean:

You already pay upfront for fool proof design and detailed requirements.  If you leverage more technology to implement your application, rather than spending more on coders, your ROI can go up significantly.

In order for entry-level coders to implement software, they need extra detailed designs. Such designs typically must be detailed enough that a coder can simply repeat patterns and fill in blanks from reasonably structured requirements. Coders make mistakes, and have misunderstandings and other costly failures and take months to complete (if nothing changes in requirements during that time).

But, again…   if you have requirements and designs that are already sufficiently structured and detailed… how much more effort is it to get a computer to repeat the patterns and fill in the blanks instead?   Leveraging technology through code generation can help a lot.

Code generation becomes a much less expensive option in cases like that because:

• There’s dramatically less human error and misunderstanding.
• Generators can do the work of a team of offshored implementers in moments… and repeat the performance over and over again at the whim of business analysts.
• Quality Assurance gets much easier…  it’s just a matter of testing each pattern, rather than each detail.  (and while you’re at it, you can generate unit tests as well.)

Code generation is not perfect: it requires very experienced developers to architect and implement an intelligent code generation solution. Naturally, such solutions tend to require experienced people to maintain (because in sufficiently dynamic systems, there will always be implementation pattern changes)  There’s also the one-off stuff that just doesn’t make sense to generate…  (but that all has to be done anyway.)

Actual savings will vary, (and in some cases may not be realized until a later iteration of the application)but typically depend on how large and well your meta data (data dictionary) is structured, and how well your designs lend themselves to code generation.  If you plan for code generation early on, you’ll probably get more out of the experience.  Trying to retro-fit generation can definitely be done (been there, done that, too), but it can be painful.

Projects I’ve worked on that used code generation happened to focus generation techniques mostly on database and data access layer components and/or UI.  Within those components, we were able to achieve 75-80% generated code in the target assemblies.  This meant that from a data dictionary, we were able to generate, for example, all of our database schema and most of our stored procedures, in one case.  In that case, for every item in our data dictionary, we estimated that we were generating about 250 lines of compilable, tested code.  In our data dictionary of about 170 items, that translated into over 400,000 lines of  code.

By contrast, projects where code generation was not used generally took longer to build, especially in cases where the data dictionaries changed during the development process.  There’s no solid apples to apples comparison, but consider hand-writing about 300,000 lines of UI code while the requirements are changing.  Trying to nail down every detail (and change) by hand was a painstaking process, and the changes forced us to adjust the QA cycle accordingly, as well.

Code generation is not a new concept.  There are TONs of tools out there, as demonstrated by this comparison of a number of them on Wikipedia.  Interestingly, some of the best tools for code generation can be as simple as XSL transforms (which opens the tool set up even more).  Code generation may also already be built into your favorite dev tools.  For example, Microsoft’s Visual Studio has had a code generation utility known as T4 built into it for the past few versions, now.   That’s just scratching the surface.

So it’s true…  Code generation is not for every project, but any project that has a large data dictionary (that might need to be changed mid stream) is an immediate candidate in my mind.  It’s especially great for User Interfaces, Database schemas and access layers, and even a lot of transform code, among others.

It’s definitely a thought worth considering.

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.