Time to Remodel the Kitchen?

Although determining full and realistic corporate valuation is a task I’ll leave to people of sterner stuff than I (since Facebook went public, not many could begin to speculate on the bigger picture of even small enterprise valuation), I’ve recently been working with a few clients whom have reminded me of why one sometimes needs to remodel.

Nowadays, information technology is often seen as a means to an end. It’s a necessary evil. It’s overhead to your real business. You joined the technological revolution, and your competitors who didn’t, well… sunk. Or… you entered the market with the proper technology in place, and, seatbelt fastened, have taken your place in the market. Good for you. You’ve got this… right?

I’m a software system architect. I envision and build out information technology. I often like to model ideas around analogies to communicate them, because it takes the tech jargon out of it. Now that I’ve painted the picture, let’s think about what’s cooking behind the office doors.

It’s been said that the kitchen is the heart of the home. When it comes to the enterprise (big and small) your company’s production might get done in the shop, but sooner or later, everyone gets fed business processes, which are often cooked in the kitchen of technology. In fact, technology is often so integral to what many companies do nowadays that it’s usually hard to tell where, in your technology stack, business and production processes begin. Indeed, processes all cycle back around, and they almost certainly end with information technology again.

Truly, we’ve come a long way since the ’70s, when implementing any form of “revolutionary” information technology was the basis of a competitive advantage. Nowadays, if you don’t have information technology in the process somewhere, you’re probably only toying with a hobby. It’s not news. Technology graduated from a revolutionary competitive advantage to the realm of commoditized overhead well over a decade ago.

Ok… ok… You have the obligatory kitchen in your home. So what?

If you think of the kitchen in your home as commoditized overhead, you probably are missing out on the even bigger value an update could bring you at appraisal time. Like a home assessment, due diligence as part of corporate valuation will turn up the rusty mouse traps behind the avocado refridgerator and under the porcelain sink:

  • Still rocking 2000 Server with ActiveX?
  • Cold Fusion skills are becoming a specialty, probably not a good talent pool in the area, might be expensive to find resources to maintain those components.
  • Did you say you can spell iSeries? Great, can you administer it?
  • No one’s even touched the SharePoint Team Services server since it was installed by folks from overseas.
  • The community that supported your Open Source components… dried up?
  • Cloud SLAs, Serviceability?
  • Compliance?
  • Disaster Management?
  • Scalability?
  • Security?
  • Documentation…?
    • Don’t even go there.

As you can see… “Everything but the kitchen sink” no longer applies. The kitchen sink is transparently accounted for as well. A well designed information technology infrastructure needs to go beyond hardware and software. It considers redundancy/disaster management, security, operating conditions, such as room to operate and grow, and of course, if there are any undue risks or burdens placed on particular technologies, vendors, or even employees. Full valuation goes further, looking outside the walls to cloud providers and social media outlets. Finally, no inspection would be complete without a look at compliance, of course.

If your information technology does not serve your investors’ needs, your CEO’s needs, your VP of Marketing and Sales’ needs, as well as production’s… but most importantly your customers’, your information technology is detracting from the valuation of your company.

If the work has been done, due diligence will show off the working utility, maintainability, security, scalability, and superior added value of the well-designed enterprise IT infrastructure refresh.

To elaborate on that, a good information technology infrastructure provides a superior customer experience no matter how a customer chooses to interact with your company. Whether it’s at the concierge’s counter, in the drive-through, at a kiosk, on the phone, at your reseller’s office, in a browser or mobile app, your customers should be satisfied with their experience.

Don’t stop with simply tossing dated appliances and replacing them. Really think about how the technologies work together, and how people work with them. This is key… if you take replacement appliances off the shelf and simply plug them in, you are (at best) merely keeping up with your competitors. If you want the full value add, you need to specialize. You need to bend the components to your processes. It’s not just what you’ve got.  It’s how you use it.  It’s the critical difference between overhead and advantage.

Maybe the Augmented Reality Kitchen won’t provide a good return on investment (yet), but… there’s probably a lot that will.

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.

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.

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. Blowplanet_collide0ing 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.success_failure1
  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.

Restoring Projects to Peak Performance

You’ve performed project triage.
You’ve run the required diagnostic tests.
It takes more than a diagnosis to avoid more implementation failures.  Now what?

Here are some quick remedies and prescriptions for fixing ailing projects:

Treatments for project illnesses
Treatments

This takes us back to the beginning of the cycle. Periodic triage and interim project health-checks are the best way to make sure your project portfolio will contain fewer implementation failures.

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.

patient history1. 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. pm_thumbnail

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?

circulatory-system1

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

practicalityIn 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.