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

The CIO's First 30 Days, Part III

Michael Wood
September 23, 2008

PART III - Assesing IT Service Levels--Satisfaction, Issues, Complexities

This is the final installment of the three part series on the strategies and tactics a newly appointed CIO can use during their first 30 days on the job to help insure their success. In this installment we will be looking at assessing how existing service levels impact how the CIO shapes their go forward strategy for IT. Once again, the answers to each question are accompanied with strategy shaping suggestions and guidelines.

What form do Service Level Agreements (SLAs) take?

Question: Is there a complete lack of SLAs?

Strategy: No need to panic. Service Level Agreements are great but only if the culture is open and supportive of the idea. Sometimes trying to implement SLAs can backfire and become a sticking point of great angst. You don’t want to create any anxiety as the new CIO since most times it gets interpreted as you being difficult to work with. However, if IT’s relationship is faltering with peers and users, then an SLA may be just the thing to indicate that the past doesn’t equal the future. Start with a very simple approach, keeping the language simple and the service level promises moderate. Allow the SLA concept to evolve and mature.

Question: Are there Verbal understandings only?

Strategy: Verbal understandings are great as long as the environment is cordial and supportive. However, should politics be in play (as they usually are) no understanding is often preferable to verbal deals. As part of your one-on-one meetings with peers and users, be sure to facilitate their sharing of expectations for, like it or not, those represent the “verbal deal.” Don’t take exception to anything that is said. Instead, take the knowledge away with you and use it to help formulate whether formal SLAs are needed. Often an informal memorandum memorializing what you heard with a thank you note for their time will keep everyone on a positive note.

Question: Do SLAs exist, but they are not used?

Strategy: A dead SLA is like having no SLA at all. Here you will want to understand the history of their creation and the reasons for their non-use. It could very well be that in the culture you are in, SLAs are a solution in search of a problem and that apathy may reign supreme. I have found it far more constructive and rewarding to promise little and deliver much, allowing the delivery of value to speak much louder than any agreement ever could.

Question: Are formal SLAs integrated into performance incentives?

Strategy: With formal SLAs in place you can assume that the IT group is more disciplined and mature than most. The question though is, is that view shared by the CEO, your peers and the user community at large. If the last CIO left under favorable circumstances then you might be lucky. However, a formal IT group that is seen as misaligned and ineffective is most likely also seen as bureaucratic and inflexible in which SLAs are merely a validation of the perception. What’s important here is to take the pulse of your constituencies to determine if they find the SLAs to be a boon or a boondoggle. If eyes roll when SLAs are mentioned, you might want to kill the program and replace it with more active and engaging face-time by yourself and your user-facing staff.

How are Service Levels Measured?

Question: Are Service Levels measured by noise (i.e., squeaky wheel gets the grease)?

Strategy: By noise I mean complaints and grumblings among the user community. If the IT group runs on current urgencies and damage control, then things are not good. Unfortunately, this mode is difficult to break as IT has usually trained the user community well in expecting staff to jump through hoops if they appear unhappy. Consider the immediate implementation of a help desk and incident tracking function. Begin the retraining process within 30 days of sending all calls for assistance through the help desk, even if your own staff has to call it in. Begin compiling service statistics and publish IT’s support track record metrics. You will need these stats to educate yourself as to what the real support issues are and to demonstrate that you are again proactive approach to leading the IT group.

Question: Are Service Levels measured by the opinions of Department Heads towards IT?

Strategy: Having your success as CIO driven by the opinions of your peers can be deadly. All too often the popularity of the CIO is the measure of their success. Unfortunately, you are apt to have to take some actions that will not support your popularity. While in the final analysis a CIO can’t survive is intensely disliked by peers, they can take actions to balance those opinions with facts, which in turn seems to reduce negative noise levels. The real key to using a quantitative, fact-based approach to shaping opinions is that you have to be very objective and accurate. Therefore if the facts say IT isn’t doing well then you have to own up to it. The good news is that during the first 30 to 90 days you can publish all the negative performance data you want and not take the blame. After that, you are the owner of all good and bad news. So use this “honeymoon” period to get all the facts on the table accompanied by well thought out plans and proposals to make improvements.

Question: Are Service Levels measured by satisfaction surveys?

Strategy: Satisfaction surveys measure perceptions and not facts. However, in the absence of facts they become the reality by which the CIO must live. Again, if surveys are an accepted tool then, get one done right away and use it as the initial benchmark that needs to be improved upon. Believe it or not, a low bar can be a good thing. So if the survey comes back with low marks there is nowhere to go but up.

Question: Are Service Levels measured by formal comparisons between baseline performance expectations against actual performance achieved?

Strategy: Here you need to become well versed in the history and trends of IT’s performance. Luckily you have the data readily available. The key now is to look for gaps between the data and the feedback your face-to-face sessions are yielding. Be sure to identify these gaps in your success roadmap along with plans on how to narrow and eliminate.

How often is the User Community surveyed as to their overall satisfaction levels?

Question: Is the user community never surveyed?

Strategy: Give serious consideration to adding a well thought-out survey to your service level arsenal. Ideally surveys should be conducted at least twice a year and after every project is implemented. This is especially true in larger organizations where the CIO can’t personally stay in touch, face-to-face, with their stakeholders and constituents. Surveys can be an excellent addition to any Voice of the Customer program.

Question: Is the user community surveyed only when management perceives a problem?

Strategy: This is a bad circumstance at best since it indicates that management is fine with witch hunts and that the past CIOs have not gotten the message that too much negative noise is bubbling up from the ranks. To fix this practice follow the guidance in #1 above.

Question: Is the user community surveyed at least annually?

Strategy: Annual surveys are good but not perfect. Surveys are best conducted when an event has ended (like a project, new application rollout, etc.) and there are specific feedback and performance related data that needs to be captured and quantified. Consider increasing frequency to the survey mix and again get a benchmark survey done right away.

Question: Is the user community surveyed at least annually and after every project?
Strategy: This is a good place to be. Review the survey content and make sure that the questions are quantified and identify expectation gaps.

SUMMING IT UP

Understanding the quality of IT service levels will help the new CIO shape their priorities over the first 18 months of tenure with the hiring company. Typically, new CIOs inherit a less than desirable environment and are tasked with turning a bad situation into a winning one. And aggressive service level improvement effort is almost always needed and done right should be self affirming with predefined improvement goals that are easy to quantify and measure.

CONCLUSION

This concludes the three part series on how the strategies and tactics adopted and deployed by newly hired CIOs during their first 30 days on the job can impact their long term success.

What are your thoughts, experiences and challenges?

We at gantthead want to know.
Copyright © 2009 gantthead.com All rights reserved.The URL for this article is:

The CIOs First 30 Days, Part II

Michael Wood
September 9, 2008

Part II- Assessing the IT Organization - Culture, Talent, Infrastructure & Maturity

This is the second installment of the three part series on the strategies and tactics a newly appointed CIO can use during their first 30 days on the job to help insure their success. In this installment we will be looking at assessing how the state of the IT organization can impact how the CIO shapes their "go-forward" strategy for IT. Once again, the answers to each question are accompanied with strategy and success roadmap-shaping suggestions and guidelines.

How big are the IT staffing levels, compensation and operating budget compared to other departments?

Question: Is IT smaller than other departments?

Strategy: Here you might want to understand why IT is spending less than other groups. Be sure to look at overall budget on a per-capita basis to insure that you are measuring like numbers. If possible, get the budgets of other departments so you can identify specific areas where IT spends less. Typically, IT payrolls are larger per-capita than other departments because it costs more to field a highly talented team of technology professionals. So if your payroll is smaller in this area, it could indicate a bias that is negative towards IT. Regardless of the reason, a small budget can be an asset as there is room to grow and thus you should begin to grow it, especially in the area of education, tools and talent.

Question: Is IT about the same as other departments?

Strategy: Like above, you should expect your payroll and education budgets to be larger than other groups'. If this is not the case, you will want to understand why.

Question: Is IT larger than other departments?

Strategy: Since you should expect a larger payroll and education budget this should not surprise you. Be aware though that if IT is not seen as a valued resource, other departments might be very resentful of the compensation and training IT staff receive. Factor this into the overall strategy if IT has service level issues and challenges. Here, you should create a compensation scheme that only rewards above average performance. Just make sure that the performance indicators are fair, objective and easily quantified and measurable.

How dependent is the company on the undocumented knowledge of its developers for the support and maintenance of custom applications?

Question: Is the company totally dependent upon less than 3 people?

Strategy: This situation can place an organization at tremendous risk, especially if the people holding the knowledge know it, are difficult to work with, and make the organization feel like it is held hostage. No matter what the attitude of this concentration of dependency, the CIO needs to quickly implement a plan to make the company independent of people’s specific knowledge in order to support, maintain and improve upon its business applications. Unfortunately, this situation exists, even in very large environments, especially when the applications in question were built by those who now are so heavily relied upon to keep them running. Painful as it might be, the CIO needs to document the applications to a level where support is transportable. One way to do this is to encourage the original developers to work with third parties to build specifications that accurately reflect what every program does, how the database is designed and how everything interacts. This can be done in layers starting with basic overviews and data models and working into documenting the detailed logic, protocols, dictionaries and rules of every application. This is expensive and difficult to do while change is happening on these very same applications, but it can be done.

Question: Is the company uncomfortably dependent?
Strategy: The same rules apply as above, but perhaps with less urgency attached.

Question: Is the company not at all dependent?
Strategy: Be thankful, and do everything you can to keep it that way.

How mature, resilient and reliable is the Infrastructure?

Question: Is the infrastructure is old and failing frequently?

Strategy: Nothing erodes IT’s credibility like an environment that is unstable and frequently failing. The good news is that it can often be fixed quickly and can make a huge impact in how the new CIO is received. The first step is to get the vendors involved and task them with proposing a solution to correct all the infrastructure defects. While they are busy getting this done, compile an analysis that quantifies the loss of business being caused by the outages. Yes, pour some salt on the wounds. If you want management to approve what could be a substantial capital investment, they will need to fully understand the value of the proposition. In addition, it will demonstrate that you are a person of well-thought-out action.

Question: Is the infrastructure aging but reliable?

Strategy: It can be difficult to sell the upgrading of an environment that is not causing pain. Here you might want to begin a phased upgrade approach. Begin by identifying current weaknesses along with the trouble signs that would signal a time to replace and upgrade aging servers, backbones, etc. This will demonstrate you are mature in your thinking and not trigger happy. Plus, as the signs appear, management will feel forewarned and be more likely to approve the expenditures.

Question: Is the infrastructure current but capacity constrained?

Strategy: Amazingly enough it is easier to get support to improve a capacity constrained in infrastructure than it is to improve an aging one that shows no visible trouble signs. When systems have varied response times, based on traffic and the like, users feel it. This causes pain and thus support for relieving the pain. If the constraint is storage, then the issue is easily quantified and thus easier to get budget to expand. Plus given the ever-declining cost of storage it makes no sense to ever have a storage constrained environment. Your initial effort is to focus on quantifying the pain points associated with the constraint and then to prepare a proposal for resolution, again showing your proactive approach to leading the IT organization.

Question: Is the infrastructure is solid as a rock?
Strategy: Send the ex-CIO a thank you note. Seriously though, if you are lucky enough to have a great infrastructure, acknowledge it and create a strategy for keeping it that way.

What kind of Disaster Recovery capability exists?

Question: Is Disaster Recovery non-existent?

Strategy: Disaster Recovery is like insurance: There is no ROI until it has to be used. If there is no Disaster Recover capability then the organization is truly at a HUGE risk. This risk is best quantified by analyzing how long the company can operate without its Information Technology working and at what incremental cost. Believe it or not this is rarely done. The ROI can then be calculated by comparing the cost of a Disaster Recovery capability to the loss that would be experienced should the IT facilities and capabilities be lost. Be sure to create several scenarios ranging from a one-day outage to total destruction. This way management can select the investment level they feel is most appropriate. If the company needs to be Sarbanes-Oxley compliant, then implementing a Disaster Recovery and Business Continuity capability isn’t an option but instead a major priority. If management fails to buy in to this you will need to constantly document your recommendations to avoid potential legal liabilities in the future. Also, you may want to keep your resume in circulation.

Question: Are there tape backups and restore procedures but no crisis management or continuity planning?

Strategy: Thinking that restoring back-up tapes is in some way an acceptable level of disaster recovery capability is like thinking a hand pump kept in the trunk of your car will help you repair a flat tire with a gaping hole in the sidewall. Essentially, follow the same strategy as above.

Question: Is there a plan, but one that is untested?

Strategy: The good news is a plan exists. The bad news is, it is untried and therefore as good as no plan. Within the first 30 days on the job, review the plan, set up testing dates and begin the planning and training for simulating outages.

Question: Is there a formal plan and processes that have been tested?
Strategy: Once again send your predecessor a thank you note and be sure to acknowledge this capability in your IT Report Cards and Status Reports.

How much of the Application Base is Custom?

Question: Are core business applications custom?

Strategy: There is nothing wrong with having custom applications supporting the core business functions. Sometimes it is the only way to support the unique requirements of the business. This is typical in industries where the potential install base is not sufficient to warrant the creation of commercial packages. That being said, be aware that the development side of your IT organization needs to be robust from design through change control. This means that you will most likely have substantially more staff than those shops in similar sized companies, which could require constant justification. During the first 30 days on the job, it is critical that you assess the ability of IT to reasonably support a custom environment. The perceptions of management and users will be quite telling in this area. Be open to suggesting that a scan of the industry for non-custom solutions might be prudent, especially if the attitudes toward the current systems related to functionality, reliability and support are low. In my experience, custom applications are a constant source of pain so if alternatives exist, even partial ones, identify them and consider initiating an exploratory initiative.

Question: Are most applications packages with modified components?

Strategy: This is the environment that most CIOs inherit. The same issues exist as in the situation above with one additional complication: You have to stay somewhat current with new releases. It is not uncommon for the reintegration of custom components into new releases to cost as much or more than the original customization efforts. Thus it is likely that the release levels you are at are sorely behind and in need of update. The worst scenario is when the release you are on is no longer supported by the vendor. This puts the organization in a high-risk situation and most likely an escalating cost situation as well. Here you need to raise a red flag right away and educate management to the exposure the current systems have placed the company in. Do it now, otherwise you risk the chance of being blamed later on for not being more proactive and assertive. Do your homework before the red flag goes up. As always, before delivering bad news, have the budget, time table, workplans, etc., all drafted and in hand.

Question: Are 90% or more of your applications packaged solutions?

Strategy: If you are lucky enough to have work in an organization that can use 90% or more of a third party solution out of the box then life could be good. First, the development side of your IT group can be kept small. You can leverage much of your support from the vendor. The down side comes if the vendor is not service-oriented or is slow in continually improving the product. One strategy is to become a player in the vendor’s user group. Getting on the board of the user group will provide you with influence that may otherwise not be available. Determine what size fish you are in the vendor’s installed base pond. Assess the relationship and take immediate steps to make any needed improvements. If you are heavily dependent upon a vendor for your core business applications then it is best to treat them as a coveted and respected ally. Request a visit to their facilities and a briefing on their future product improvement plans. Become one of their preferred reference sites (make them earn it though). In short, build their dependency on you; it makes for a more level playing field.

How large is the Project Backlog?

Question: Is the project backlog greater than two year...and growing?

Strategy: An aging and growing backlog can spell death to a CIO. If you find yourself in this situation you need to work fast to on the following crucial to-do items:

• Inventory all projects (approved and pending) and prepare an analysis of each in terms of Objective, Justification, Budget, Implementation Date, etc.
• Create a Project Portfolio Management function with a user driven oversight committee.
  Assess the quality of the PM organization and identify improvement imperatives.
• Present the “State of the Projects” to the committee and have them make prioritization and future direction decisions.
• Prepare a committee endorsed request for additional resources needed to achieve the committee’s directives and present to the leadership committee (CEO’s team).

You may or may not get all of what you ask for but you have logically and prudently identified key issues and demonstrated your ability to create consensus. These are powerful credits to management seeing you as the right choice for the job.

Question: Does the backlog go back about 12 months?

Strategy: A 12-month project backlog is not unreasonable. You should still take steps to commission a PPM function and user driven steering committee.

Question: Do you have a rolling backlog of about six months?

Strategy: You are in the good health zone. Stay there.

Question: Does your backlog consist of only a few projects?

Strategy: Just make sure that there aren’t more projects that need to be started. Sometimes too little is a sign of frustration and reluctance by users to ask for anything new.

SUMMING IT UP

The quality if the IT organization’s culture, talent, infrastructure and maturity are huge factors in shaping the newly hired CIO's potential for success. Amazingly, if the inherited environment is too good the CIO might find it difficult to make improvements and thus appear ineffective. If the environment is too faulty, the CIO may not be able to create positive change fast enough to be deemed successful. Ideally a new CIO’s best chances for survival is to inherit an IT group that is primarily strong, perhaps suffers from some relationship issues but has a great deal of talent and potential that is just in need of caring cultivation and quality leadership.

Next issue we will be tackling Assessing IT Service Levels – Satisfaction, Issues, Complexities and how the quality and state of service levels of the newly hired CIO impact their long term success roadmap.

Copyright © 2009 gantthead.com All rights reserved.

The CIOs First 30 Days, Part I

Hans Robbers – Said it best; Feb 19, 2009 - "Great article with questions not only applying to a new CIO role but also when you take over as a pm, often due to unfavourable circumstances. The questions make you think and help to define a strategy to bring things back on track thanks for the insight"

The CIOs First 30 Days, Part I

Michael Wood
August 26, 2008

Congratulations, you just accepted a job as CIO, now what? Having survived nine years as a CIO, I can assure you that your success is more dependent on how you are thought of by the CEO and your peers than on what you know. So, let’s explore some possible success strategies.

Over the next few weeks the following strategy shaping areas of being a new CIO will be explored:

• Building Peer Constituencies & Assessing Perceptions
• Assessing the IT Organization - Culture, Talent, Infrastructure & Maturity
• Assessing the Service Levels – Satisfaction, Issues, Complexities

Each installment will present a series of questions, the answers to which will influence the strategies, tactics and actions you pursue as you establish your foundation for success as a CIO. Keep in mind that each question may have multiple answers that apply.

PART I - ASSESSING EXECUTIVE LEADERSHIP & PEER GROUP PERCEPTIONS

When starting a new position as a CIO it is critical to assess how top management views the IT organization and specifically the performance of the last person in the job. No matter how good a CIO you think you are, you are never better than how the CEO and the executive management team (your peers) perceive you to be. Within the first 30 days of becoming a CIO you need to do a rapid 360-degree assessment of what peers, IT staff and key vendors think about prior CIO, IT, Management and Users. These views are your inheritance from the prior CIO and the news could be good or bad.

What were the circumstances of the other CIO’s leaving?

Question: Was the prior CIO fired, or did he or she resign under unfavorable circumstances?

Strategy: This most likely means there are hostile feelings toward IT and you will inherit them. Here your strategy is to distance yourself from your predecessor. During your first weeks on the job, it is imperative you visit the CEO and your peers, enlist their counsel, facilitate their frustrations and have them help you to shape priorities as they see them. By expressing interest in their situation, by providing them a cathartic release, you are building credibility and that might be exactly what you need to make a positive impact. Don’t editorialize or make promises. Just listen, feedback to them what your heard and thank them for their guidance. Also, request a time to meet with some of their staff to get their insights and input. Reaching out and engaging your peers and their organizations is IMPERATIVE. It is perhaps the fastest way of differentiating yourself from the prior CIO.

Question: Did the prior CIO retire or resign under favorable conditions?

Strategy: Here your strategy is to “Hope to Measure Up” to your predecessor. Having someone’s shoes to fill is not always easy. When you are replacing a prior CIO who was liked as well as effective, you need to find out what attributes, approaches and behaviors about that CIO successfully worked for them. Here, having time with the prior CIO is very important. If possible, have the prior CIO introduce you to their peers and verbally endorse you as the “Hand Picked” successor. Be humble and express your hopes that you can do justice to the endorsement. If the CIO has already left and is unavailable then spend your first few weeks understanding the IT organization, the project backlogs, the processes that are in place, etc.
During that same period meet with the CEO (one-on-one) to get his or her views and guidance and to learn more about your peers. Armed with this knowledge, meet with your peers and key people from their organizations to learn about their priorities, issues and concerns. Document what you learned and see how it aligns with what you know about the CEO’s expectations and the IT organization’s ability to deliver. Build your next month’s strategy around resolving alignment issues and develop written plans to that end.

Question: Is this a newly-created CIO position?

Strategy: Understanding why the organization has decided to create a CIO position will serve you well. Here your strategy is to demonstrate an open mind and a customer focused, collaborative attitude. Typically, along with new “C” level positions comes an increased expectation as to the quality of services, flexibility and agility that the IT group will provide the company.
Once again, within the first few weeks of taking the reins of CIO, it important to meet with the CEO and your peers to establish a rapport and collegial framework upon which to build. Soliciting their ideas and opinions as to what they are hoping for from a CIO is critical. During this perception and expectation discovery effort you must take on the role of facilitator. Never promise, brag, boast or do anything that would increase expectations or provide a baseline upon which you may later be judged. Instead, be humble and totally focused on their needs and concerns. In other words, listen, take copious notes, verify your understanding of their views through paraphrasing, and other active listening skills.

What is the on-time delivery track record of IT on projects?

Question: Are projects consistently delivered on time and within budget?

Strategy: Should you be so lucky to inherit an IT organization with a consistent track record of delivering projects on time and within budget, rejoice! Your strategy here is to first compile the metrics on the last 12 to 18 months of projects as well as the current projects in process and awaiting start. Organize the lists by stakeholders and meet with them to confirm the past accomplishments and to review their expectations for the future. This will indicate that you are engaged in the process and are proactive in your efforts to continue and improve on a positive trend.

Question: Do projects consistently run over budget?

Strategy: Believe it or not, the only people usually concerned with over-budget projects are the CEO and CFO. Delivering on time is usually what really counts on projects. That being said, if you find projects are consistently over budget, it’s a weakness and needs to be improved upon. Meet with your project managers to review the past 12 to 18 months of projects and get their take on what the issues have been and how they plan to correct the budgetary issues. Then, meet with peers who had a stake in the over budget projects, acknowledge the past deficiencies and get their feedback and guidance on the issue. Finally, as part of the “go forward” strategy, include a section on resolving poor project budget performance issues.

Question: Do projects consistently miss their delivery dates?

Strategy: Missing project delivery dates can be deadly. If this is the situation that you have inherited as the new CIO, then you need to remedy it quickly. Again, meet with the PMs to get their input on the issues. Go through each project and document the rationales provided. Most likely scope creep and changing priorities will be identified. If the PMs insist that they are victims of the situation, you may want to consider new PMs in the not too distant future. Also, link project performance to future pay increases and bonuses if that has not already been done. Finally, meet with stakeholder peers, acknowledge and condemn the past poor performance, get their feedback and follow-up with a memo outlining the corrective actions that will be implemented within the next 60 days.

What are the feelings and attitudes of key users towards IT?

Question: Are user attitudes openly negative and dismissive towards IT? Do users appear not to trust promises and commitments made?

Strategy: All too often, new CIOs find that the past CIOs have left a very bad taste in the mouths of management and users. When the negativity reaches dangerous proportions then time is very short for the new CIO to demonstrate that things will be better under the new regime. The biggest mistake here is to make broad and sweeping promises about the future. Instead, the savvy CIO will create an environment where the user community has more hands-on involvement in the prioritizing and managing of projects. By increasing user ownership and accountability in future projects, the CIO can increase overall buy-in. Of course if the negativity is at the service level and system reliability level, the CIO may need to implement sweeping changes. Again, promises will fall empty and only action will count. Consider implementing a formal help desk and incident tracking system. Immediately become very visible to the user community; attend their meetings, do lunch, demonstrate interest in their plight and needs. Finally, look long and hard at the IT organization for defects and flaws in structure, talent and attitudes. If the negativity toward IT is focused on a few individuals, take them out of the spotlight and evaluate their future with the organization.

Question: Do users seem evasive in expressing opinions about IT?

Strategy: Evasiveness usually equals unhappiness. Political concerns usually inhibit candid opinions among users. When this is encountered, turn the dialog away from IT (and people) and toward business processes, applications and capabilities. Zoom in on what users find frustrating. Consider conducting a series of cross-functional facilitation work sessions where users can identify the things that impede their job performance and where they can educate you on how work is performed. Here you will want to develop workflow models interactively with these groups. As you document their issues and their desired resolutions you will demonstrate caring, interest and understanding. They will see you as open and intelligent; all good.

Question: Do users have a positive attitude toward IT staff but not so much about the applications they use?

Strategy: A lucky CIO has a well-liked staff. When the users like the IT staff, they are less likely to complain to management that things are bad. If the applications are frustrating them, then a similar approach to the cross-functional facilitation work sessions is recommended. Here the issues that are brought up should be focused on application deficiencies and what and possible improvements. Each of these improvements should be systematically mapped to workflow models. Be sure to include your application analysts and experts in these sessions. Based on the data collected, have your application experts perform an impact analysis on the improvements identified. Next, parse the improvements into a series of short-throw projects and present them to each group for shaping. Finally, on those projects that have high acceptance, create project proposals and jointly present them to management for approval. Management will be impressed that you have reached out to the user community, build constituencies and a shared consensus for improving operational efficiency.

Question: Are users mixed in terms of their views on IT staff and applications they use?

Strategy: Follow the same strategy as above.

SUMMING IT UP

As you can see, considering the above questions can have quite an influence of how, as a new CIO, the roadmap for success gets constructed. Next issue we will explore how an Assessment of the IT Organization - Culture, Talent, Infrastructure & Maturity can impact your success roadmap.

Copyright © 2009 gantthead.com All rights reserved.