On Project Audit...

By Andy Jordan

In this article I want to provide an overview of what I think the most useful form of project audit is, and why it’s of benefit to an organization to conduct periodic audits.

To some of you this may be a new concept; to others, you may have been subjected to (or performed) project audits already. Either way, it’s worth defining my view of an audit as it may be different from yours. To me, an audit is a review of different aspects of a project by an expert from outside of the project. Typically this will be a PMO function and may cover a number of different aspects--compliance, results, timeliness, etc.

You may have slightly different definitions within your organizations, but I am going to work from this one for this article. I’m deliberately avoiding things like one-off audits of a specific project which are usually focused more on the specific deliverables/challenges of that initiative, rather than on project management as a whole.

The best kind of audit
By their nature, audits can look at a multitude of different aspects of a project, but I strongly feel that they deliver the best results when targeted appropriately. An audit that looks to ensure that every box is correctly completed on a status report is not going to do much to advance project management discipline, and it may set it back by alienating project managers.

Instead, an audit should focus on the process of project management, and the following questions are key:

• Is each step in the process achieving its intended goals?
• Are the tools and templates adequately supporting each step in the process?
• Are the processes being complied with and are the standards being met?
• Is management of the project consistent with other similar projects?

For a PMO that’s focused on improving the way that projects are executed, this should be sufficient. Anything more granular than this becomes an analysis of the details of the way that a PM manages and runs the risk of getting into issues of different project management styles.

The way that the audit is conducted is also important. Many of you will have been subjected to more formal audit processes where nameless people walk around saying nothing and making notes--it’s not a comfortable situation.

Far better is to make the audit a collaborative process. Have the auditor work with the project manager, and position the audit as a chance to improve the way that projects are handled across the entire organization (more on that later). Even the way that the questions are asked can make a huge difference. For example, “How easy do you find it to follow that template?” is likely to get a much more constructive (and ultimately helpful) response than “Why don’t you fill in this box?”

Maybe most important of all is the way that project managers see auditors. The natural reaction by most PMs is to see the auditor as “against” them, and I always try and turn that around. If I am auditing, I will start by meeting with the project manager to discuss the areas that are likely to be of focus, but in a way that makes the PM an integral part of the process. A question as simple as “What part of the process do you find the most frustrating?” is an easy way to try and identify areas of focus in a way that encourages the PM to be part of the process.

The audit process
For an audit to be successful, you have to know how it is carried out. Is this simply going to be a series of questions and a review of documentation, or is there going to be a quantitative element as well? If you are looking at data, then what data points are going to be considered and what can they be compared against? There may be some value in knowing that the PM spends two hours a week updating the project plan, but there’s a lot more value in knowing what the numbers are from other projects to have something to compare against.

If the process is purely qualitative, then how will you ask questions: interviews, group discussions, questionnaires or a combination? How will you present the questions to the team? You need to get honest feedback rather than the answers that they think you want, but you also need to make sure that it’s not a confrontational relationship that could cause them to shut down completely.

There needs to be consistency in the way that audits are conducted. You need to be able to compare results across projects--both similar and different. The most meaningful results are not the data elements or findings from one particular project, but rather the trends that occur across projects.

Finally, you need to consider how many projects will be audited. It likely isn’t practical to audit every project (although it may be possible to capture data points on completed projects), but what is the correct mix of projects based on type, size, project manager, etc.? In some cases, you may want to audit the same project multiple times--especially if it’s a long-term initiative.

Analyzing the audit
The most important part of a project audit is going to be interpreting results and acting accordingly. This is an area that can lead to mistakes, so care is needed. In some cases, trends will occur across audits--one particular template or process that just doesn’t seem to be working. That’s easy to address--you revisit the process and make adjustments to try and address the identified problems. Then you reassess after the changes have been made to see whether the expected improvements have occurred. Similarly, if a project manager is struggling with one particular aspect, it may signify a need for training of that individual--a quick lift in their skills that solves the problem permanently.

Not all audit findings are so clear-cut, however. Consider the project manager who isn’t following one aspect of the process. Is this simply a training issue, or is there something else going on? Is it possible that the PM in question has actually found a better way of doing things? It’s entirely possible that the outcome of this audit should be a change to the process to include the changes that the project manager made on their own initiative. That’s not to say that there shouldn’t also be some training for the PM on the right way to introduce process enhancements, but the auditor should never lose sight of the overall goals of the audit process--to improve the quality of project management within the organization.

Conclusion
Audits should be an important part of the PMO’s governance of projects within an organization. They are a connection to what is actually happening on projects. While audits can be a “stick” that forces compliance with process, that’s not the real value they bring. Instead, they should be able to help identify areas that require focus to improve the way that projects should be managed. Far from being something to be feared, that’s something that project managers should embrace--after all, you all want a better way of managing projects.

Marketing your Project

Author : Michael Wood [sourced by Kuttan]

Why do some projects need a marketing campaign and what’s involved in the effort?

To answer this question we first need to understand some basics about what marketing is all about, what a marketing campaign is designed to accomplish--and what role marketing can play in contributing to project success.

First, not all projects warrant a full-blown marketing campaign effort. Projects that have sweeping organizational impact, require large capital investments, tend to be politically sensitive and span more than a year are typical candidates for a formal marketing approach.

As Wikipedia puts it: Marketing is an integrated communications-based process through which individuals and communities discover that existing and newly-identified needs and wants may be satisfied by the products and services of others.

Some projects may even benefit from a branding effort that captures the essence of the project in its name or slogan. Again, turning to Wikipedia, the following definition of a brand can be found: A brand is a name, term, design, symbol or other feature that distinguishes products and services from competitive offerings. A brand represents the consumers’ experience with an organization, product or service. A brand is more than a name, design or symbol. Brand reflects personality of the company which is organizational culture.

Although the benefits of correctly marketing a project can be many, applying these concepts to projects is not always easy. The following concepts are intended to help you in your project marketing efforts.

There are two basic phases to marketing a project. The first phase (pre-approval) deals with promoting the project with the goal of gaining stakeholder support and management’s approval. The second phase (post-approval) focuses on maintaining momentum, keeping the project positioned in a pro-active and positive light and conditioning stakeholders toward the changes the project’s implementation will deliver. This article will focus on the pre-approval aspects of marketing your projects.

During the pre-approval phase there are a few specific goals that your plan needs to achieve. First, it should stimulate thinking on ways to make optimal use of organizational resources. This requires a compelling business case stated in very simple business terms that identify the outcome to be achieved along with the associated investment. For example, consider the following case for improving the effectiveness of direct marketing adapted from a real project:

Streamlining the Direct Marketing system at Acme Widgets will save over $3 million a year in promotional costs while enhancing sales by 15 percent. This can be achieved by the end of 2010 with a dedicated team of 12 and an investment of $750,000.

This example is simple, easy to understand and draws the reader into asking “How?”--and allows for further promotion of the project to interested parties and hopefully garnering support.

In addition to stimulating thinking, the pre-approval marketing effort needs to be clear as to the roles and responsibilities of those conducting the marketing effort. Here, more often than not, less equals more. Communications need to be controlled and deliberate, thus idle chatter among would-be team members to outsiders needs to be managed. Think press releases, not water cooler gossip.

Just as in political campaigns, talking points need to be well thought out and consistent without seeming rehearsed or appearing to be mindless regurgitations of the “party line”. Thus, there should only be one or two project spokespersons that are intimate with the project’s details as well as proficient speakers and presenters. These spokespersons must also have a firm grasp of the obstacles that will need to be overcome in order to sell the project--including lack of credibility, political opponents, scarcity of capital funds and overall economic conditions. For every obstacle identified, specific responses need to be crafted and shaped that bring the focus of the issue back to the benefits to be gained through the project’s implementation.

For example, it is reasonable to expect that both time needed to achieve, the investment identified and outcome promised will draw critics’ eyes. Here, facts--not sound bites--will win the day. By delving deeper into the assumptions supporting the costs and benefits of the project, attention is moved from the end numbers and toward the framework that was used to support those numbers. Thus, those objecting to the project must invest time in understanding the assumptions and how they were used in order to be credible opponents. Using our direct marketing example, the following objection handling talking points might be used:

Objection: How is it possible to save $3 million a year in direct marketing costs via a streamlining effort?

Response: Currently, our direct marketing campaigns average 150,000 items per mailing and are based on a “shotgun” approach resulting in less than a 1 percent response rate (1,500). Using a more scientific approach, based on customer preferences, buying habits and other demographic and psychographic data, our tests have indicated we can sponsor campaigns of 5,000 to 30,000 mailings and yield over 20 percent response rates (avg. 6,000). This alone will save us an average of 75 percent on direct mailing costs while increasing responses fourfold.

Notice how the facts are quite granular, compelling and authoritative. If the person posing the objection is not intimate with the details, they are hard-pressed to challenge. In addition, assuming the facts are correct, additional inspection only serves to strengthen the business case for the initiative. Thus the marketing effort achieves yet another major goal of the plan--progressively advancing the project toward approval.

In their book Innovation Happens Elsewhere: Open Source as Business Strategy, authors Ron Goldman and Richard P. Garbiel share these thoughts related to the story behind your project--your marketing plan:

“A compelling story that describes what your project is aiming at--something to get people excited about it. This is the message that will attract people to your project both as users and potential developers.The story needs to express the shared purpose behind your project. It will attract people who share this vision and are willing to work to make it real.”

In preparing the pre-approval marketing plan, consider the following steps:

1. Develop a business case based on solid facts and research including stakeholders; economic realities; soft and hard investments; time and effort needed for success; and, most of all, what success looks like in terms of improved revenues, reduced costs, larger market shares, new customer capture, increased customer loyalty, etc.

2. Identify the challenges and obstacles that would lead to management not approving the project

3. Craft a benefit statement that draws the reader into asking hard and challenging questions that are easily answered by the facts and effectively disarm challenges and obstacles.

4. Identify the core talking points and spokespersons for marketing the project

5. Define the campaign in terms of media blitzes, campaign presentations, print and electronic media (brochures, websites, video, data sheets, etc.).

6. Define the campaign’s reach, milestones and timetable for completion

7. Test the campaign where possible on prospective sponsors.

8. Develop a detailed proposal and executive level presentation for pitching the project to management and key stakeholders

9. Launch the campaign leaving room for recalibration every week or two.

10. Culminate the campaign with the pitch to management, being sure to have as many supporting stakeholders present at the presentation.

Marketing a project is like marketing any product launch: It requires a deliberate and well-thought-out plan that is geared to achieve one and only one outcome--a “yes” from management. The more grassroots support you have for the project—and the better researched your facts are--the more likely you will be to achieve a resounding “yes” from management.

Good luck with your efforts. Let us know what approaches have worked on marketing your projects and any lessons learned from unsuccessful efforts.

Managing Projects...

- Article by Ramanathan V, SetProve Consultancy

“Ram, most of our projects are going be-yond timelines and the estimated efforts. I don't think people are to be blamed as I see this problem even for projects executed by my best project manager” - confessed Surya, CEO of Startsoft Technology.

The first round of meeting with the project leads led me to a large list of excuses like “unforeseeable difficulties”. “took longer than expected”, “unexpected changes from client”. Even the most prestigious projects where everyone’s attention was focused and every expert was ready to assist - even those had slipped on schedules or effort estimates. They believed their estimations were wrong and tried to implement Function Point Analysis (FPA) with pain but no gain.

I noticed a common thread in almost all excuses that they are all expressions of uncertainty. Estimation cannot be certain because we talking about work to be done in future. Extrapolations are not always correct! But every project manager knows about it! That is why he adds a “safety factor‟ to all his estimates. Yet this has not given any comfort or increased the level of confidence for completing the project on time.

Even in FPA there are estimates, and most project manager don't understand why and how they estimate truly. Let use take an example. If we ask how long it will take (make an estimate) to reach home from office, you may say about 25 minutes. If we ask what you mean by “about‟, then explanations could be like “it may take 15 minutes or some times 1 hour - you see if there is some unforeseen problem like a flat tire it may take even 1 hour and 20 minutes. So “about‟ means “more often”. You can substitute a good driver to a good programmer, flat tire to technical glitch etc. So in this example if you call an experienced project manger to commit to an estimate, you will be surprised to see he may estimate it at around 45 minutes. But often he cannot explain his adding such a large safety factor moving estimate from 25 minutes to 45, except he may say it is based on “experience‟.

It is true that often project managers quote arithmetic mean as estimate. Then they will add some amount to it as safety. People who understand statistics immediately imagine a normal bell shaped curve but in reality if they can draw a graph on occurrences it will look like the one given below. In this distribution (unlike normal distribution) the number that covers most occurrences (say 90%@) is much farther than arithmetic mean or even median value. So project mangers must understand statistics in its practical application scenarios to provide good estimates.

But it still does not answer the question that if there is a large safety factor why do the project schedules slip!

Senior management too are guilty of their lack of understanding of statistics. Very often in the negotiation they try to bring the estimate number closer to averages (mean, median or mode) as they argue that average represent most likely scenario. So even the large safety factors are significantly trimmed without understanding underlying distribution.

By the way how many in senior management or project management know when to use “mean‟, “median‟ or “mode‟ or know differences between normal and skewed distribution? So FPA or not, project managers start with wrong understanding of distribution.

But the worst part is that after the estimation and as soon as the work commences they forget about the purpose behind the safety factor. You will very often see that “Late start date‟ is used more often than “Early start date‟. Don't you know most school students do their homework only at the last minute?

But it is not always the psychology behind using “late start‟. If you are to get material from vendors to start that task, delaying from “early start‟ to “late start‟ means delaying material procurement, that means delaying investment till the last minute. Every prudent finance manager would love that! Given every project manager works with resource constraints - more time (meaning late start) gives the buffer to ensure resource availability.

So mere introduction of sophisticated tools like FPA may not guarantee success unless the project managers have an in depth understanding of what they are using, why they are using and more critically how it impacts their project work.

Mere project schedules on MS project software or knowing about PERT/CPM will not help. When I read the book “Critical Chain‟$ I realized why often CPM (critical path method) did not help me! We require project managers who continue to learn new ideas in project management. They have to understand and improve their knowledge on practical application aspects of methods. If estimation is about future and thus brings uncertainty, we must credit project managers who do anticipate other risks that bring more uncertainty. Risk identification and management is critical act every project manager is supposed to do.

In this specific case I noticed that the team is not clear on a few aspects of specification and the project manager has written is his project plan that they must obtain clarity quickly. But yet in the midst of the project, this requirement is buried, but to resurface when they were in the midst of a crisis. Then the project manager is forced to accept what the customer says even if it will take more time. Now I see why there is a reason for delay like ‟unexpected changes from client‟.

Most risk management has apart from “contingency planning#‟ a key element namely “mitigation planning‟. If contingency plan is re-active strategy, mitigation plan is pro-active. It details what the project manager should do to mitigate (or reduce chances of) risk occurrence. Often mitigation plans are not prepared, but the equally sad part is that even when prepared they are forgotten (like safety factor!).

The reason ‟unexpected changes from client‟ should read as “not implementing mitigation plan‟. Project management more often is not about living with uncertainty but ability to understand what causes uncertainty and managing it. Understanding uncertainty begins with learning new subjects, techniques and continues with exploring the difficulty when those learning fail in practice.

$ - Critical Chain by Eliyahu M Goldratt

# - Contingency plans include specific strategies and actions to deal with specific variances to assumptions resulting in a particular problem