Project Management for Policy Administration System Replacements: Art or Science

As anyone can tell you, project management is a key cornerstone to the successful completion of any project, but for extraordinary projects, like Policy Administration System Replacement projects, a more sophisticated level of project management is needed. But what does a more sophisticated level project management look like? The myriad of project management disciplines and methodologies out there can give the impression that complex projects require a project management approach that is more scientific and systematic, when in actuality, the more complex the project the less systematic project management gets. This is a counter-intuitive notion, since one would naturally think the more complex the project (i.e., Policy Administration System Replacement project) the greater the need for a systematic project management approach to make sure nothing is missed. This is not to say the project management disciplines and methodologies out there offer no value on a Policy Administration System Replacement project, because they most certainly do.  However, when managing a Policy Administration System Replacement a project manager should always keep in mind that those methodologies and tools are merely a starting point (i.e. the “canvas”) for that masterpiece that is successfully managing an endeavor of significant size and complexity in practice.

When practicing the art of project management, there are a number of tactics that should be adhered to, particularly on a Policy Administration System Replacement project, which you are not going to find in the PMBOK. These tactics are not hard-and-fast rules in terms of execution, but are more fluid. What do I mean?  Well let me provide 4 examples of what I mean:

1. Don’t Fall into the Form-Over-Substance Trap – I have seen project managers that can pull together very detailed and comprehensive project plans, create one hell of a status report, capture every risk and issue on a log, and follow whatever management methodology selected for a project to the tee and yet the project fails. In the project postmortem, there are many reasons for a project failure, but in my experience the majority comes down to management. Adherence to project management dogma over substance is a project killer and focusing too much on the paper work rather than results of what really matters does no one any good. Bottom-Line: Use project management methodology and tools as a starting point only and never mistake project administration for project management, because they are not the same thing. So not only should managers not be afraid to deviate from methodology, if they can see how it could provide additional value to the project team and/or the client, a manager should look for opportunities to do so since staying on the strait-and-narrow will bread rigidity that will ultimately doom the project when it does come time to decisively change direction. The art of this approach is in the notion that managers need to know when to let, that which truly does not matter, go when there is a need to focus on critical issues. Reschedule/skip that regularly scheduled meeting, don’t obsess about missing that status report submittal, if the project plan doesn’t get update for a few days that is ok.  Those things are not project management; project management is about knowing when those things don’t matter in light of the overall project goals.
2. Pay Attention to Your Instinct –  Missing a due date on a project plan, having an identified risk go into red status, being alarmed by the number of bugs being logged  on a just release build of the system code; these are not the primary indicators that there is a project issue. A project manager on a Policy Administration System Replacement project should intuitively know about these issues well before those types of indicators manifest themselves in the normal project management documentation.  It is counter to the way many talk about/view project management, but in Policy Administration System Replacement projects, project managers need to place just as much reliance on the gut than the head in many situations given that they almost never have all the detailed information at hand.  If a project manager is blind-sided by any of these happenings (and yes it will happened at least once on the project), then chances are the project manager is discounting the intuition side of the equation.  If it doesn’t feel right then it is probably not right. Trust that feeling on a Policy Administration System Replacement project and start to take action. In all likelihood it could end up saving the project.
3. Get On A One-On-One Level – Policy Administration System Replacement projects are large undertakings, involving many people from across locations, organizations, departments, and disciplines; not to mention walks of life. Often it is tough, if not a practical impossibility, to meet all team members face-to-face or talk one-on-one at least once, let alone regularly.  And the advice that, even despite these typically challenges, the project manager should try to meet all the all team members face-to-face or talk one-on-one at least once during the project is not revolutionary, but what I am trying to get at here is that there is another level that needs to be reached. To manage a Policy Administration System Replacement project the “one-on-one talk” is a key strategy for successful project management. The one-on-one conversation is where managers can get key pieces of information, but it is not something best achieved in an overly procedural manner. Picking out a few key people on the project t and scheduling a recurring one-on-one conference call will not do. With that approach it will not take long for the feedback to become obligatory and stale. Sometimes you get your best results when the person does not know when the project manager is going to call to get a status or inquire about their feelings on how the project is going. Also the “key people” you need to talk to are not always the people in the key project roles. A project manager on a Policy Administration System Replacement project will need to figure out who and when to call; that is the art of the process. The one-on-one conversation should be informal, but these types of discussion should be a common occurrence regardless of project status or stage. The one-on-one conversations a manager has on the Policy Administration System Replacement is often more important than the regularly schedule status and team meetings that are a staple of all projects (big and small).
4. Listen More Then You Talk At Status Meetings – On a Policy Administration System Replacement project it is a practical impossibility for the project manager to read every email, be up-to-speed on what everyone is working on and the status of the applicable tasks all the time, which is why the art of listening gets a special place in the management of a Policy Administration System Replacement project.  And I don’t necessarily mean listen to the specifics of each team member report, because, while the technical/operational details of a report is of course important, how a team member gives their report is often more important. You can get technical status details in an email, but you can’t get other details that are perhaps more telling, like: body language, pauses, voice inflections, etc. These tell-tale-signs indicate whether a team member really knows what their assignment is, how it is progressing, are they disengaged from the project, etc.  This information will help the project manager determine who he/she needs to follow up with outside the team meeting and who is on track and therefore need less oversight in the short-term. If managers ignore this type of involuntary feedback, they could miss personnel/ operational task issues that could result in level project issues if not address.

There are of course more non-traditional tactics employed in the management of a Policy Administration System Replacement project, but the main point is to try to shift the thinking that the key successful project management of a Policy Administration System Replacement is a greater adherence to methodology and tools. Project management is an art as well as a science and the Policy Administration System Replacement project requires at least an equal measure of both to be successful.

Ten Ways to Ensure Project Failure

Sometime ago I read an article about the top ten ways to destroy the earth. Although it is a bit morbid to even think about such a topic let alone compile a top ten list, it certainly is an interesting scientific problem. Blowing planet earth to bits is not as simple as it may seem. It takes considerable amount of energy to blow up six sextillion tons of rock and metal. However, there are some exotic ways to get the job done. From creating a micro black-hole on the surface of the earth to creating an anti-matter bomb with 2.5 trillion tons of anti-matter to creating perfect Von Neumann machines (self-replicating), they are all pretty futuristic and not part of our everyday experience. Some may say- “why even think about such an absurd subject?”, but it does have few practical applications. If nothing else, it helps us think about possible dangers to the only known planet capable of supporting life.

While blowing up earth may for now be out of our grasp and may require giant leaps in technology, blowing up an IT project is quite easy. I can say that with authority, because I have seen many projects self-destruct right in front of my eyes and at times I may have contributed to some of them. So here are the ten ways of blowing up an IT project:

1. The Missing Matter—Requirements: Lack of business and functional requirements or requirements lacking appropriate level of detail.
2. Progress Black Hole: Lack of mechanisms to measure progress, milestones, and deadlines.
3. Caught in the Gravitational Pull of Technology: Focus on technology itself rather than achieving business objectives through technology.
4. Supernova – Out of Resources: Unrealistic expectations and deadlines – trying to achieve too much in too little time and with too few resources.
5. Consumed by Nebulous Clouds: Constantly changing requirements and feature creep. Inability to give the project and product a solid shape and direction. Lack of proper change control process.
6. Bombarded by Asteroids: Loss of focus and progress due to multi-tasking on unnecessary side projects and other distractions.
7. Lost in Space: Lack of a well defined project plan with appropriate level of details, milestones, and resource allocations.
8. Too many WIMPS (Weakly Interacting Massive Particles): Lack of interaction with the business users, lack of sufficient number of check points, lack of business user involvement during the planning, build, and deployment phases.
9. Journey to the Edge of the Universe: Attempting to run a project with bleeding edge technology, inexperienced project team, and poorly understood business objectives.
10. Starless Solar System: Lack of clear and convincing business case and mapping of how the project will help to achieve the business objectives.

Preparing for Project Rescue: Diagnosis

In my last project management blog post, I talked about performing triage on a project portfolio.  Over at the Oracle Infogram blog, they picked up on our post with a reminder that triage is a pervasive activity, and one that is essential to project management:

“Triage runs from the queuing on the CPU all the way up to the user’s daily calendar entries, it is a concept that should always be kept in mind when planning and building projects.”

The result of the triage effort is to identify those projects most in need of immediate intervention.  Just as in the medical world, the next step after triage is diagnosis; now it’s time to focus on projects in the third group and perform project diagnostics. If you are tasked with rescuing a failing project, here are the first steps that you should take to find the root cause(s) of the project’s difficulties.

1. Obtain a thorough patient history: Skilled medical diagnosticians may not rely solely on the patient’s recollection. In some cases they need to interview family and friends to obtain information on subtle symptoms.  Likewise, the skilled project diagnostician should combine the skills of Dr. Gregory House and Dr. Cal Lightman.  When trying to diagnose failing projects, they shouldn’t don’t rely solely on direct interviews of the project team. A multi-perspective view of the situation is needed:

• Have a closed-door session with the project sponsor: Find out what the key issues are with the project and begin to explore areas where a rescoping might help bring things back on track. Find out what kind of scope reductions are likely to be accepted by the business, and which might require significant salesmanship or a fierce battle. Understand the organization’s politics so that you can factor them into your corrective action plan.
• Talk to the project stakeholders about their original expectations, their current concerns, and any difficulties they may be experiencing with the project team.
• Create comfortable communication channels with all members of the project team, and dig deeper than project plans, status reports and issues logs. Find out what is causing project anxiety within the team.  There are often valuable clues here. Be sure to probe any areas that are glossed over or brushed aside quickly.

 2. Next, take the project’s vital signs:

• Pulse check: Assess the burn rate. Are you eating up budget faster than you anticipated? What is the new estimated total cost?
• Blood pressure: perform a risk assessment, in terms of what could happen between now and the go live date to cause a significant incident. Various frameworks exist for this assessment. The Six Sigma FMEA template can be modified to suit your needs here, giving you an objective framework for assessing all possible places where your solution could fail, and steering your future corrective actions toward those that have both the highest likelihood of occurrence and greatest criticality.
• Temperature:  Red yellow green heat sheet with respect to key milestones. This should be part of your regular status report, along with some basic trending. For example, we once managed a huge portfolio of interdependent concurrent projects with weekly reviews that tracked both last week’s and the current week’s milestone status. Because we were in an M&A situation facing TSA deadlines, we had not time to bring up robust project portfolio management tools, so we kept things moving with simple, homegrown Excel tracking tools.
• Other specialized diagnostic tests as needed—assess the scope (original and current), review the technology strategy, development strategy, testing strategy, release strategy and change management strategies.

After performing these steps, you should have insight into why the project has gotten off track. Our next blog post will cover some of the intervention steps to take after the diagnosis is complete.

How often do you perform project triage?

A quick google search shows that the medical concept of triage is commonly applied to evaluating IT projects and other major business initiatives. 

The concept of triage comes from medicine, and in particular medical treatment under difficult circumstances—war, epidemic, disaster—where the number of people needing treatment exceeds the resources available. In such situations, the sick or injured are typically assigned to one of three groups.

 In the business context, it usually means allocating scarce cash and human capital under difficult economic conditions, when the number of ongoing projects exceeds the level available resources.

Project Triage Framework

In the current economic climate, it probably makes sense to perform a mini-triage of your project portfolio quarterly, with an annual triage as the last fiscal quarter approaches.  In addition, you may be faced with the need to triage in emergency situations such as a sudden shift in business strategy, in the face of a new acquisition, or when presented with an across the board budget cut. Periodic review is a cornerstone of an effective project portfolio management strategy. This regular triage can be a valuable form of project insurance. Preventative medicine is always less costly than crisis treatment.

Your triage team should include your senior IT management as well as functional business leadership. Performing project triage is easiest if there is regular, reliable status reporting from the project teams, on their milestone and budget status.

Triage is also easier if your project initiation process includes a business case that assigns a business criticality score to the project. It’s entirely possible that business criticality of a given project might change over the course of the project’s lifecycle, and a master project status tracking document helps the triage team keep track of this.

After reviewing the health of individual projects and their alignment with current business needs, triage will place them into three groups which align perfectly with the medical definition of triage:

1. Persons who are likely to live even if they don’t receive immediate treatment—projects going well that need no additional intervention

2. Persons who are likely to die even if they do receive immediate treatment– projects that you should suspend NOW before they chew up additional resources

3. Persons who are like to live only if they receive immediate treatment– projects that need you to perform an immediate intervention

Our next blog post will cover specific diagnostic tests you must perform on projects that fall into the third group. In the meantime, let us know your apporach to project triage by answering this poll:

How often do you perform project triage?

Does your Order-to-Cash Process Need a Check-up?

The order-to-cash process is the circulatory system of every business. As with the human circulatory system, there are many ways this process can break down, and seriously erode the overall health of the business.

Diagnosing and fixing order-to-cash symptoms is not easy, because the order-to-cash process is complex from many perspectives. It involves:

• Multiple technology systems or application modules
• Multiple locations
• Multiple departments and job roles
• Multiple stakeholders

Much of the inefficiency we see in this core business process arises from an inappropriate approach to making decisions and changes concerning any of the technology or business processes involved in order-to-cash.

Without strict change control over the processes and technology, some companies are allowing decisions to be made on the fly, resulting in in an order-to-cash process that yields significantly less cash than it should!  Some real world examples from our project teams include:

Symptom: A CPG company that required a return merchandise authorization (RMA)  to match the quantities on a purchase order (PO).  Some of their customers returned products across multiple POs.When a customer service rep could not find these POs, they created a new PO just to process the return against. This workaround skews information inappropriately in any number of reports.

• Diagnosis: It’s not just this process that’s broken. The company needs to devote more effort to process definition, with review of exception handling by all impacted stakeholders.

Symptom: High volume of billing errors, requiring significant effort in reviewing/correcting invoices and handling customer inquiries. Your staff might also be trying to review every order and every invoice because of the historically high rates of errors. You’ll start to see a drag on your Days Sales Outstanding (DSO) metric as well.

• Diagnosis: There are many possible causes here: price lists and promotions being maintained offline, manual re-entry of orders from handwritten order forms, lack of automation in the order approval workflow, undue delays in entering orders, manual handoffs to fulfillment team, to name a few. While there are many causes,it’s easy to see that investments in automation here can have a significant effect on cash flow (especially important in the current economy), because even a small reduction in DSO can have huge returns.

Symptom: High volume of customer inquiries and high volume of customer complaints, coupled with long average call times, as well as repeated or escalated calls to follow up on the same issue.

• Diagnosis: The CSRs may not have real-time access to the right information to address customer inquiries (order status, credit hold status, account balances). Tighter integration and better training can often address this.

Other organizations realize that an ounce of prevention is worth a pound of cure, and proactively monitor key performance indicators (KPIs) across the order-to-cash process. These include:

Contact to sales order: leads (number and cost), qualification (lead conversion ratio), quote (gross margin and average discount) and closing (win/loss ratio and time to close/sales cycle).

Order fulfillment: Order-to-delivery performance data includes metrics related to customer orders (number of new or open orders and number of orders with errors, number of orders delivered on the date promised to the customer

 Invoice to cash: Metrics include number and value of invoices created, sent and disputed as well as cash received or accounts receivable days outstanding.

In summary, to make sure your order-to-cash process is not leaking cash, adopt the following measures:

1. Strict change control over all the processes and technology.
2. Adopt and track key metrics to help you find and address inefficiencies.
3. Take a look at the integrated operating platform between your customer relationship management (CRM), Order Entry, Finance and Supply Chain Management systems.  Too many manual interventions across the lifecycle of an order leave the doors wide open for errors on orders and invoices that could significantly impact your bottom line.

Practical Project Management

In times like this every PMP needs a healthy dose of a new and improved PMP, that is, project management practicality. As the recession lingers, those of us who drive the success of projects, programs, and any corporate initiative are going to have to find new ways of doing more with less.  Here are seven practical tips for cutting corners without sacrificing project success.

1. Curtail time-consuming interviews for requirements-gathering. There are several easy ways to cut the effort required to gather information from subject matter experts:

• Group them by functional area (when appropriate) and avoid interviewing single stakeholders.
  
• Use structured information gathering templates and require that they take a pass through them and begin filling in the required information before the meeting. The keyword here is structured. I prefer Excel templates with restricted ranges of responses, rigidly enforced with data validation limiting those responses to list.  STructure the information you need into columns, apply data validation, and put explanatory notes as a cell comment in the column headers.

2. Make your meetings more productive.

• Know your goals. Have an agenda and be ruthless about sticking to it.
• Limit the attendees to those people with decision-making authority
  and real subject matter expertise. Bigger meetings cost more and waste more time.
• Appoint a live note-taker. The note-taker should type the notes live during the meeting and send them out before the end of the day. Transcribing from written notes is wasted effort.

3. Restructure your project team. Combine roles and responsibilities, because fewer roles mean fewer handoffs. It’s better to have a smaller team running above 100% utilization than a larger team at or under 100% utilization.

4. Carefully define the scope of your analysis/requirements gathering effort. Don’t waste time documenting standard business processes in excessive detail; concentrate on the areas that have unique and/or critical requirements.

5. Hold the line on customizations. They add cost to the current project, and will complicate upgrade and migration projects down the road.

6. Request a mini-business case for custom reports. Every custom report should have a place in the spec that describes the business action that the report enables, as well as a list of alternative sources for the requested information if the custom report is not available. This will help the project sponsor make an informed decision when approving the custom report request.

7. Make project status more transparent. To reiterate an earlier post on PMOs: A well-defined, user-friendly, and well-maintained project portal site can cut down on the need for lengthy status meetings. Milestone status, next week’s key tasks, and open action items can be posted to the portal site. A weekly meeting can be used for exception-based reporting on lagging milestones and critical issues, allowing the project sponsor and key stakeholders to participate in resolution during the meeting.