The Art of War - Awesome book

Written by Sun Tzu in the 6th century BC

The Project Audit from Andy Jordan Perspective

Andy Jordan is President of Roffensian Consulting Inc. and I really enjoyed reading Andy's perspective on the The Project Audit.

Over the months and years I’ve written about a lot of aspects of a PMO, but I’ve never touched on a project audit. 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 processFor 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 auditThe 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.

What I believe to be my top 5 attributes of being a successful BU Leader

1. Know when to Lead and when to follow – In order to be an effective leader, you need to be an effective follower.
2. Be a 360 degree Leader - Looking at the whole picture or larger context of how something will impact those above, beside, and below you.
3. Differentiate between the art of managing a organization versus the science/managerial side - The art side requires strong communication, vision and interpersonal skills. The science side requires detailed knowledge of methodologies and tools as well as problem solving skills.
4. Effective Communicator – Ensure that the right information gets to the right people at the right time.
5. Pay attention to detail – Oftentimes, people only focus on the really big issues and lose sight of the smaller issues. It is a cliché but it’s true that sometimes it’s the small foxes that spoil the vine.
   

Boiling the IT Frog:

Here’s a great book that I found quite interesting, this book explains all of the things about IT that business people really need to know. The funny thing about it, is that it isn't the technical stuff; it's the IT issues caused by various factors outside the control of the IT group — the things that tend to make IT unsuccessful no matter who the people are in the IT or business roles.

This book was written by Harwell Thrasher:

Boiling the IT Frog:

How to Make Your Business Information Technology Wildly SuccessfulWithout Having to Learn Anything Technical

Thrasher believed that IT is more about people than about technology, and that most IT problems come from misunderstandings between business and technology people. Wouldn't it be great if there was a book that IT people could give to their business customers to help explain the issues faced by IT organizations?

Thrasher put some of the most important things he learned during his thirty-plus years of IT experience into a 183-page book that's written in business language (no technical gibberish). It doesn't explain the technology itself — there are lots of books that do that — it instead describes the critical aspects of IT management that business people need to understand, including answers to questions like:

• Why does software – which doesn't wear out – have to be maintained?
• Why does IT infrastructure cost so much?
• Why can't I specify a project's scope, cost and schedule?
• How do we select the best projects for the business?
• How can we assure project success?
• How can we better define business requirements?
• How should IT be measured?
• Why do we need an IT strategy, and how do we create one?
• Should our IT be outsourced? Offshored?
• What responsibilities should IT have? Should business have?
• Why can't I understand what my IT people tell me?
• Why isn't Information Technology simple?

My 4 Offshore red flags

Gregory L. Seawright

I wanted to share my four (4) red flags/experiences as an individual on the “bleeding edge” of managing a variety of offshore resources and development teams. I know that many of you have asked how do I get the best ROI on my offshore resources, how do I reduce risk, and improve quality?


Well you really need to consider:

The Culture (differences), the enormous amount of staff turnover, and the costs are all red flags or danger signs for offshore resources. I have personally seen how the Big 5 Consulting companies (KPMG, CAP Gemini…even HP) have successfully placed strategies to address these dangers/risks.


However, if you are a CIO, Sr. Director, Sr. Program Manger with any type of experience in offshore team development/resource efforts, you already know that quality of your code is a critical factor: if the code that is produced offshore doesn’t meet your customer requirements, then you can surely expect issues such as poor customer satisfaction, project delays, SLA's and increased code errors to become a very harsh reality.

Think Like a CEO

Gregory L. Seawright

I want to share with you my take on how a Program/Project Managers should view each project as part of a wider organizational need and treating projects like businesses.

Think Like a CEO

So what does it really mean for a Project Manager to think like a CEO and treat projects like a business?

First and foremost, it means understanding how organizations work and creating value for their shareholders, customers and the various business units.

For shareholders, the business creates value when it provides a return on its investment (ROI) that meets their expectations for the amount of risk a company/shareholder has invested. The problem is that many projects won’t directly impact a company’s bottom line. Project managers also need to consider the project’s overall impact on the company’s tactical and strategic objectives to see where the project creates value. For example, new product projects often impact profitability and create high levels of profit, while a project that focuses on breaking into a new market probably won't break even. But both projects to some degree will contribute to the company’s overall strategy/bottom line.

My 10 Project Management Principles

Gregory L. Seawright

As a Business Unit Manager, I typically follow the following principles when managing projects:

1. Focus on Triple Constraint: Cost, Quality, and Time
2. Effective Planning
3. Primal leadership - Leading with emotional intelligence and understanding my team
4. Understand the organization’s discipline, methodologies, and PM lifecycle
5. Communication, Communication, and more Communication
6. Establish clear objectives, goals, and requirements
7. Get rid of the old folklore mentality - “Make it fast. Make it good. Make it cheap.”
8. You can’t achieve great things without great people…acquire/hire the best talent By acquiring the best people -- the most skilled, the most experienced, the best qualified -- the project manager can often compensate for too little time or money or other project constraints.
9. Establish project priorities upfront
10. Simplicity rules – keep it simple