You are currently browsing the category archive for the 'Project Management' category.
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.
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. Blow
ing 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:
- The Missing Matter—Requirements: Lack of business and functional requirements or requirements lacking appropriate level of detail.
- Progress Black Hole: Lack of mechanisms to measure progress, milestones, and deadlines.
- Caught in the Gravitational Pull of Technology: Focus on technology itself rather than achieving business objectives through technology.
- Supernova – Out of Resources: Unrealistic expectations and deadlines – trying to achieve too much in too little time and with too few resources.
- 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.
- Bombarded by Asteroids: Loss of focus and progress due to multi-tasking on unnecessary side projects and other distractions.
- Lost in Space: Lack of a well defined project plan with appropriate level of details, milestones, and resource allocations.
- 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.
- Journey to the Edge of the Universe: Attempting to run a project with bleeding edge technology, inexperienced project team, and poorly understood business objectives.
- Starless Solar System: Lack of clear and convincing business case and mapping of how the project will help to achieve the business objectives.
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
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.
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.
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:
ROI communication & calculation can make a difference in a project getting funded or not
In today’s economic climate justifying the cost and benefits of an IT initiative has become more important than ever. Often the fate of an IT project depends on the justification of benefits and recuperation of the costs. Therefore calculating, presenting, and demonstrating the benefits of a project in an appropriate manner can make the difference between getting a green light and getting stuck in an endless review cycle.
Value-statements can help bridge the communication gap
During my interactions with various IT departments I have noticed that the IT staff values a project differently than the business sponsors or executive team. Calculating and communicating the value of an IT project puts the IT staff in an uncomfortable and unfamiliar role which requires financial, sales, and technical skills. Quite often even when the IT staff tries to focus on business benefits they fail to align the benefits of a project to the business concerns in a manner that resonates with the executive team. The use of appropriate terms and prioritization of business concerns is key to grabbing the attention of the business sponsors and the executive team. A value statement [i]can be a useful tool to summarize and contextualize benefits of a project in almost all circumstances. Sometimes there are cases when ROI is not clearly defined, is impossible to define, or simply not that important to the stakeholders. Under such circumstances a value statement can be instrumental or even a must. They help overcome resistance, bind together stakeholders, and focus the project around delivering real business value. To summarize, they help you see the forest from the trees where as ROI calculations help you count the trees.
A value statement can take many shapes and formats depending on the context of the project and audience reviewing it. However, it is always a good idea to try and tie it back to the mission or value statement of the project. For example consider the following sample value statement:
The benefits need to be tied back to the capabilities by linking them to preferably operational measures. Financial measures although are more accurate they typically lag operational measures.
Calculating ROI
When calculating direct [i]and indirect [ii]benefits of a project it is important to keep three important aspects in mind:
- The Rate of Return of the Investment
- Capital Recovery Horizon
- Variance Potential
The rate of return of the investment is not just returns exceeding the original investment plus the cost of capital but it should also include compensation for the risk of undertaking the project. For example if a project returns 20% and cost of capital is 18% then the additional 2% may not be sufficient justification even for a “sure shot” of a project. As a very rough rule of thumb ROI of less than twice the cost of capital should be considered high-risk. A ROI of 4 times or more of the cost of capital is considered ideal. Capital recovery horizon is the time that a project will need to generate enough benefits to recover the original investment. The rapid pace at which technology, business environment, trends, and preferences change (especially in the IT industry) pose a significant risk of future benefits not being realized. Changing market conditions and new competition can create new more lucrative opportunities as well diminish the value of existing ones. Therefore it is highly desirable to recoup the original investment as quickly as possible to minimize exposure to sudden changes in market conditions. The ideal recovery time can vary significantly and depends significantly on the market conditions and maturity of a given vertical. For fast moving verticals recovery time of 1 to 2 years is ideal. Variance potential portrays the risk associated with changes or variances in the calculations and estimates of the future benefits of a project. Indirect benefits are hard to calculate accurately and are most susceptible to errors and variances. If indirect benefits constitute a high percentage of the overall benefits or a project then the variance potential for the project is high and vice-versa. Indirect benefits that are less than 50% of the overall benefits are ideal whereas a number of 90% or more indicates high risk to the project.
Calculating the ROI with appropriate level of rigor can be a daunting task. Coming up with a justification for a project is not a “one size fits all” exercise and does not always have to result in punching numbers and formulas into a spreadsheet. Depending on the type of project and the company the right type of benefits calculation has to be tied to the appropriate level of rigor. Sometimes a clear and well articulated value-statement can be sufficient while at other times you have to have hard numbers to backup your claim. A simplified ROI sheet that ties the benefits to the operational levers (operational capabilities) is presented below.
[i] A value statement focus more on the qualitative aspects rather than the quantitative ones, it is simply narrates the benefits without tying it to the bottom-line.
[ii] Direct benefits are the ones that are only one step removed or are a direct consequence of the implementation of the project (e.g. hardware/software/staff consolidation, time savings, inventory reductions, increase in revenue, etc.).
[iii] Indirect benefits are the sub-consequence of the change brought about the project implementation or are the unquantifiable side-effects (e.g. improvement in morale & good will, more knowledgeable support staff, increase in revenue, etc.).
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:
- Strict change control over all the processes and technology.
- Adopt and track key metrics to help you find and address inefficiencies.
- 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.
IT due diligence on a software startup may seem unnecessary if the core product offering represents a significant new advancement. It really can’t be overlooked, however, as there are many technology risks lurking within the product and within the company itself.
As far as the core technology offering(s), it’s important to conduct code reviews, architecture reviews, security audits, application performance assessments (especially in light of the projected growth in the business plan) and an assessment of the company’s software development lifecycle methodology.
There are other hidden risks, some of them far removed from the core product offering, that may impact your future acquisition’s ability to achieve its goals. Many of them stem from the need to be both chief cook and bottle washer during the very earliest days of the company’s existence. Here are the top three:
- Inappropriate software development practices: My favorite example here is a startup I was advising during its search for first round investors. They could not resist the urge to keep “improving” the code, so they never segmented or froze their brainchild into discrete releases. The night before I had scheduled a potential investor for a demo, they thought of four new “must-have” features to add, and were actually debugging during a demo that failed to execute.
- Tendency to re-invent the wheel: Software entrepreneurs are often skeptical of packaged enterprise software to the extent that they will build their own backoffice, CRM, or other applications. The risk this imposes to potential investors is twofold: you are retaining dedicated staff to support those applications, and any migration off of these applications may be difficult because they are often built “on the side” without sufficient documentation.
- Project management immaturity: It’s unusual for a startup to hire real project managers very early on in their lifecycle. While PM discipline could certainly help them during the concept phase, it’s absolutely necessary as they are attempting their first deployments to clients. Weaknesses in this area are easy to spot as you conduct due diligence interviews with their customers.
So even if the product has no competition in the market place, and you’re convinced it can sustain competitive advantage, please make sure you have qualified resources do some deep probing to help you understand where the hidden problems may lie.
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.
When looking at the results of our last poll on collaboration styles, several things jumped out at us.
1. Nearly a third of the respondents are either still relying on email collaboration or under-utilizing basic portal functionality (document checkout/checkin for version control).
2. Among users of collaboration portals, there was an even split between Sharepoint and other tools.
This led us to wonder how broad corporate adoption of collaboration tools might be. And it leads us, of course, to another poll.
Comments always welcome, and in case you missed the first post in this series, it’s still open and you can vote here.
