It has only been a few weeks into the new year but I think we are off to a good start here at recipeforIT.com. Given the significant number of new readers, I thought I would touch again on the key goals for this site and also give you a preview of upcoming posts and pages.
As many of you know, delivering IT today, with all of the cost reduction demands, the rapidly changing technology, the impact of IT consumerization, and security and risk demands, is, simply put, tough work. It is complicated and hard work to get the complex IT mechanism, with all the usual legacy systems issues, to perform as well as the business requires. So to help those IT leaders out, I have started this site to provide recipes and ideas on how to tackle the tough but solvable problems they face. And in addition to providing best practices, we will give you a solid and sensible perspective on the latest trends and technologies.
So what is upcoming? First, I have two esteemed former colleagues who have run top notch service desks that will be authoring material on best practices and how to deliver an outstanding customer experience through this critical interface. Look for their posts on the ‘face of IT’ over the next several weeks. Second, I want to touch on innovation and the increasingly common business fascination with innovation as a solution to all manner of business ills. I hope to also explore leadership further in February. And lastly, I have a number of incremental but hopefully material improvements to the site pages that will provide further details on best practices in a comprehensive manner.
I think it is a good lineup for the next month! I continue to receive strong feedback from many of you on the usefulness and actionability of the material. I will definitely work to ensure we maintain that relevance.
Don’t forget you can subscribe to the site so you get an email when there’s a new post (subscribing is on the rightmost bar, halfway down the page). And feel free to provide comments or suggestions — the feedback really helps!
If you are new to the site, I recommend a few posts for relevance and fundamentals:
In recent posts, I have noted previous articles on how the recovery in the US has been a ‘jobless’ recovery yet one with stronger investment in equipment and IT. This peculiar effect in the latest reporting appears to be even more pronounced, perhaps even running in ‘overdrive’. According to yesterday’s Wall Street Journal article, the investment in labor savings in the US stepped up at the beginning of the decade, but with the recession, companies found bigger opportunities to automate even more with machinery and software. Timothy Aeppel, the author notes, this investment and spending level has continued broadly through the fourth quarter. And while certainly investment in technology will cause employment subsequently to rise, I think it appears that CEOs are investing in technology far more than adding staff as in previous recoveries. And they are doing this for a reason — they can get better returns from the machinery and robotics and software than before. Part of this is due to low interest rates and unique tax breaks, but I believe that technology is enabling greater returns on reducing costs and improving productivity than previously. Further, I think fundamental changes in IT capabilities and robotics are fueling improved returns from automation even more than has occurred in the past, spurring even greater investment in IT.
Historically, IT applications and systems were applied to domains with large amounts of the routine work, often done by hundreds if not thousands of staff. These were the areas that justified the cost of IT and provided the greatest return. Improvements in application and database technology enabled technology to tackle tougher and more complex problems. It also enabled leverage of technology on medium scale processes. Basic toolsets like email and Sharepoint tackled the least complex and departmental processes. This progress is represented in the diagram below.
The introduction of client server platforms allowed solutions to be applied to routine work on a smaller scale, to large departments and medium sized companies rather than just divisions and large corporations. This accelerated with the internet and the advent of virtualization.
But the cumulative and accelerating effect of new development technologies and methods, new toolsets, new client devices, cloud infrastructure, and advancing data and analytics capabilities has enabled a far broader range of solutions to be applied easily and effectively across a wide range of institutions and problem sets. Small and medium sized companies through cloud services can now leverage similar infrastructure capabilities that previously could only be implemented and afforded by the largest corporations. This step change in progression is represented by the chart below.
The increase of automation scope with new Tech toolsets
The new lightweight workflow tools like IBM’s Lombardi toolset and many others open up almost any departmental process to be easily and rapidly automated and achieve a decent ROI. The proliferation of client interfaces through the internet and mobile allow customers to self serve intelligently for almost any product and service, enabling the elimination of large amounts of front office and back office work. This cumulative and compounding effect is truly a step change in what can be done by IT to automate the work within medium and large companies. And yet, despite this sea change in capabilities, you still find many IT departments focused almost wholely on their traditional scope. The projection initiation and selection process is laborious and even arduous, oriented towards doing large (and fewer) projects. The amount of overhead required to execute almost any typical project would overwhelm lightweight automation for departmental-sized efforts. And yet, there are huge new areas of scope and automation that are possible now in almost every company. And so how do you start to prove out these new areas and adapt your processes to enable them to get done?
1. Improve customer signup or account opening: Unless your company has redone these functions within the past 24 months, it is doubtful that this area is up to the latest expectations of customers. Enable account opening from the web and mobile devices, leverage the app stores to provide mobile clients that have additional, useful and cool functions (nearest store, nearest ATM, or if you are a climbing gear company, the current temperature and weather at base camp on Mount Everest). Make them easy to navigate and progress through the application with progress bar and associated menu. Ensure the physical process at the store or branch is as easy as the internet version (i.e., not twenty pages of forms). And tighten up the security with strong passwords (many sites today have a strength indicator as you type in the new password) and two factor security on critical transactions (e.g. wire transfers or bill payments). Remember you can now deliver the two factor security through the customer’s mobile device and not a separate token.
2. Fix two or three process issues that are basic transactions for customers: Just as you need to continually cycle back through your customer interfaces to keep them fresh and take advantage of the latest consumer technology, you should also need to revisit some of the basic transactions that business typically fail to put on their list to invest and yet become problematic service areas for customers. These would be areas like change of address or statement reprints or getting a replacement card. Because they are never on the project list, these services remain backwaters of process and automation with predictable frustration for the customers, high error rates, and disproportionate manual effort to complete. Work with a strong business partner (perhaps the COO or someone close to the customer experience) to tee these up. Use the latest workflow tools to tackle the process piece. Leverage the latest data warehouse and ETL capabilities to integrate the customer data across business units and applications so that the process can be once and done. If you are not sure on what basic customer process to start, then talk to the unit handling customer complaints and look for those processes that have the highest number of issues yet the customer is trying to do something quite basic. Remember, every customer complaint requires expensive responses that by eliminating, you drive material improvements in productivity and cost.
3. Implement more self-service: An oft-neglected area is the improvement of corporate support functions and their productivity and service. In a typical corporation almost every employee is touched by the HR and Fiance processes, which can be heavily manual and archaic (again they rarely show up on the project list) By working with your Finance and HR functions you can reduce their costs and improve their delivery to their users through implementation of automation and self-service. The advanced workflow toolsets (IBM’s BPM) mean you can do far more with incremental, small tiger team efforts than ever before. Your scope to automate and move to self service on your intranet is much greater. More and more minor business processes than ever before can be automated at far less cost and effort. The end results are higher productivity for your business, lower operations costs in HR and Finance, a more satisfied user base, and a better perception of IT.
4. Get to a modern production and service toolset for IT: For the past twenty years, there have been two traditional toolsets that most companies leveraged for production processes and service requests (Remedy and Peregrine). And most of us have implemented (with some struggle) reasonable implementations that met the bulk of our needs. But the latest generation of these toolsets (e.g., ServiceNow) make our previous implementations look like dinosaurs. And when you consider the 60 or 70% of your staff and service desk are using these tools every day, and you can make them far more productive with a new toolset, it is worth taking a look at. Further, your business users, will love the new IT ordering facilities on the intranet that are better than ordering a book from Amazon. By the way, the all-in operating cost of the new tools should be substantially less than your current costs for Remedy or Peregrine. And your team will be operating at a step level improvement in efficiency and productivity.
5. Get Going in Business intelligence: One last item to make sure your company is capitalizing on is leveraging the data you already have to know your customer better, improve your products or services, and reduce your costs. Why have advertising for customers who never click through or buy? Why do customers call your call center when they should be able to do it easier online? Wade through all the unstructured data being generated on social about your company to figure out how to improve your brand. Knowing the mood of the market, understanding your customers and the perspectives on your products and services requires IT to partner with the business to leverage the data you have to obtain intelligence. Investing in this area can now be tackled with the new big data tools on the market. If you are not doing much here, then I recommend finding out what your competitors are doing and sitting down with your business partners to sort through what you must do.
So, there’s 5 things that five years ago, would have never made any list. Yet if you make real progress in 3 of the 5, you can hit home runs in customer satisfaction, service quality, and a much better view of IT. And most important, you can ensure your company stays ahead of the game to achieve greater productivity and lower costs.
Any views or alternate perspectives on the progression of IT tools and solutions? Do you see the same sea change that I am calling out here for us to take advantage of?
As you start out this year as an IT leader and you are trying to meet both project demand on one hand and savings goals on the other, remember to leverage what I term the IT ‘Flow of Work‘. Too often, once work comes into an organization, either through a new project going into production or through the original structure of the work, it is static. The work, whether it is server administration, batch job execution, or routine fixes, continues to be done by the same team that often developed it in the project cycle. Or at best, the system and its support are handed off to a dedicated run team, that continues to treat it as ‘custom’ work. In other words, once the system has been crafted by the project team, the regular work to run, maintain, and fix the system continues to be custom-crafted work.
This situation, where the work is static and continues to be executed by the initial, higher cost resources, would be analogous to a car company crafting a prototype or concept car, and then using that same team to produce every single subsequent car of that model with the same ‘craft’ approach. This of course does not happen as the car company moves the prototype to a production factory where the work is standardized and automated and leaned, and far lower cost resources execute the work. Yet in the IT industry we often fail to leverage this ‘flow of work’. We use senior server engineers to do basic server administration tasks (thus making it custom work). We fail to ‘package’ or productionalize or automate the tasks thus requiring exorbitant amounts of manual work because the project focused on delivering the feature and there was not optimization step to get it into the IT ‘factory’.
Below is a diagram that represents the flow of work that should occur in your IT organization.
Moving work to where it is most efficiently executed
The custom work, work done for new design, or complex analysis or maintenance, is the work done by your most capable and expensive resources. Yet, many IT organization waste these resources by doing custom work where it doesn’t matter. A case in point would be anywhere that you have IT projects leveraging custom designed and built servers/storage/middleware (custom work) instead of standardized templates (common work). And rarely do you see those tasks documented and automated such that they can be executed by the IT Operations team (routine work). And not only do you then waste your best resources on design that adds minimal business value, you then do not have those best resources available to do the new projects and initiatives the business needs to have done. Or similarly, your senior and high cost engineers are doing routine administrative work because that is how the work was implemented in production. Later, no investment has been made to document or package up this routine work so it can easily be done by your junior or mid-level engineering resources.
Further, I would suggest that you often find the common or routine engineering work stays in that domain. Investment is infrequently made to further shrinkwrap and automate and document the routine administrative tasks your mid-level engineers so that you can hand it off to the IT Operations staff to execute as part of their regular routine (and by the way, the Ops team typically executes these tasks with much greater precision than the engineering teams).
So, rather than fall into the traps of having static pools of work within your organization, drive and investment so that the work can be continually packaged and executed at a more optimal level and free up your specialty resources to tackle more business problems. Set a bar for each of your teams for productivity improvements. Enable them the time and investment to package the work and send it to the optimal pool. Encourage your teams to partner with the group that will receive their work on the next step of the flow. And make sure they understand that for every bit of more routine work that they can transition to their partner team, they will receive more rewarding custom work.
After a few cycles of executing the flow of work within your organization, you will find you have gained significant capacity and reduced your cost to execute routine work substantially. This enables you to achieve a much improved ratio of run cost versus build costs by continually compressing the run costs.
I have seen this approach executed with great effect in both large and mid-sized organizations. Have you been part of or lead similar exercises? What results did you see?
In the past several weeks, I have posted on project management best practices. And we talked about the track record of the IT industry as being, at best, a mixed bag. It turns out for the UK government, that would be putting a very positive spin on their IT projects. The Times recently ran an article* detailing the eight worst areas in the government which have cost the taxpayers dearly. IT projects had 3 blatant failures of the eight and had a major hand in 2 of the remaining. How did it come to this? Why is practice of IT reasonable for more than half of the UK government wasteful initiatives? And these are not minor blowups. The Fire and Rescue Plan, which started out as a 120 million pound effort to consolidate 46 control rooms to 9 regional centres was finally axed after it cost 469 million pounds! A straightforward project (how many of us have consolidated call centres, trading floors or command centres in the past 10 years? I would venture 50% of your firms have done this) that cost 4 times the estimate and never even delivered! And that is not the worst one: the NHS records project has cost 6.4 billion pounds to date with at least 2.7 billion of that wasted. While there are 60 million citizens in the UK, many of us in industry have customer bases in the tens of millions where we keep critical financial data safe and accessible for our customers. So while I would agree the health records breaks new ground in some areas, it is not the Manhattan project. This is a very doable project where given the monies spent, it should have already delivered significant benefit and capability. And yet very little has been delivered and there is low confidence this will change in the near future for the program. Overall, how can IT projects have 3 of the 8 slots of government failure areas when the defense industry only has 1 (and you could argue IT projects contributed heavily to that one)?
I think this dismal track record in government for IT projects is due to some common issues and a few unique ones. First, typically there is poor and ambiguous sponsorship. And it is compounded by very weak and changing requirements. Too many parties and groups in government with a stake and a reason to argue and change the project. Applying the methods of political processes of lengthy debate, consensus and influence to defining and running a project are a recipe for disaster. And I suspect the contractors doing the work likely encouraged changes and debate as this was then an opportunity to grow scope with much higher margin work (change orders are always much more profitable than the original bid). Second, the approach undoubtably used a waterfall method. And given the size and scope and vast array of stakeholders, each step (e.g. requirements definition, etc) took an extremely elongated time. An elongated schedule with a cumbersome and bloated program structure to match the stakeholder complexity would certainly have multiplied the costs. Still, it takes even more to cause such spectacular blowups.
There is an excellent book, Software Runaways, available that documents such ‘death march’ projects. ‘Death march’ projects are the kind of massive program that everyone knows is doomed to failure and yet everyone is still lashed to the ship on this voyage to failure. It is a fascinating read and some ways like watching a traffic accident unfold — it’s pretty awful but you can’t tear yourself away. Of course, the UK government and its contractors do not have a monopoly on such spectacular program failures (though they certainly seem to be doing their best to enable additional chapters to be written). What is relevant here though is that the book does an excellent job of reviewing about a dozen of the more interesting past IT program failures and identifying the root causes. These rot cause include the poor sponsorship and ill-defined requirements we discussed above. But it also describes the mentality that sets into a large program team on their ‘death march’. In essence, even though the members of the team know there are massive flaws in the program, because of the complexities and different agendas and influences of a large complex program team, they are often unable to repair them from within. Even worse, when an external party identifies the flaws, the program team then bands together to defend from such external attacks at all costs. Their identity has become so caught up in the program that they would create a Potemkin village to demonstrate that there are no flaws.
So, it is the instinct of these large program organizations that assume a life of their own with all the members now vested in its survival (not its delivery but its survival) that when combined with major flaws (such as ill-defined requirements or the wrong methodology) creates the spectacular failures. Or, put another way, it is how humans work together within large programs that if based on poor practices, can be multiplied to raise the negative results to such an irrational level.
With that in mind, what are some approaches to prevent this from occurring? I would suggest the basic ones of ensuring there is clear sponsorship, proper steering committees should help, but more radical changes to the approach would be better. Let’s take the command centre consolidation. Why do all 46 into 9 in one waterfall or ‘big bang’ approach? Instead take two regions of the 9 and do two pilots, each constructed with their separate sponsors, steering committees and contractors. Set an overall schedule for them to deliver to a well-defined, but high level set of requirements or outcomes. The team that completes their work on time and meets the requirements will have an opportunity to bid on the next two regions to be consolidated. And the one that does not meet the bar will result in the contractor being barred from the next round of work and a negative performance mark will go on the sponsors and government leads. Now, the payoff for contractor encouraging endless changes by government is gone. Further, you are breaking up the work into more doable components that can then be improved in the next regional implementation. Smaller problems sets are eminently more doable then massive ones. By changing the approach to more incremental work with short cycles and aligning program structure and incentives to getting real results, I think you would find a dramatic difference in the delivery of the project.
While these changes would certainly improve project delivery, I am sure there are several other elements that have caused impact and problems. What would you change? How do we get IT projects to not be a huge portion of wasted taxpayer funds?
I look forward to your comments.
Best, Jim
* The Times, which is a very good newspaper, unfortunately does not provide access to its articles via the internet without a subscription. If you have a subscription, the article title is ‘Scandal of the big spenders who have cost taxpayers dear’ published on January 9, 2012.
I hope that you are back from holidays well-rested and ready to go for the new year. My previous post provided some tips on how to get off to great start of the new year, today’s post will focus on some additional best practices for Project Delivery (I covered project initiation and project reporting and communication practices in my December post on project delivery). Today, I will cover project management best practices. I expect to also extend these posts with a project delivery best practices pages that will cover more details over the next month.
As I previously mentioned, project delivery is one of the critical services that IT provides. And yet our track record as industry of project delivery is at best a mixed bag. Many of our business partners do not have confidence in predictable and successful IT project delivery. And the evidence supports their lack of confidence as a number of different studies over the past five years put the industry success rate below 70% or even 50%. A good reference in fact is the Dr. Dobbs site where a 2010 survey found project success rates to be:
Ad-hoc projects: 49% are successful, 37% are challenged, and 14% are failures.
Iterative projects: 61% are successful, 28% are challenged, and 11% are failures.
Agile projects: 60% are successful, 28% are challenged, and 12% are failures.
Traditional projects: 47% are successful, 36% are challenged, and 17% are failures.
So, obviously not a stellar track record in the industry. And while you may feel that you a doing a good job of project delivery, typically this means the most visible projects are doing okay or even well, but there are issues elsewhere in less visible or lower priority projects.
There are also a few critical techniques to overcome obstacles including how to get the right resource mix, doing the tough stuff first, and when to use a waterfall approach versus incremental or agile. I will cover the first two areas today and the rest over the few weeks.
Project Management – I think one of the key positive trends in the past decade has been the rise of certified project managers (PMP) and the leverage of a PMI education and structure for project activities. These learnings and structure have substantially raised the level of discipline and knowledge of the project management process. But, like many templates, if used without adjustment and with minimal understanding of the drivers of project failures, you can have a well-run project that is not going to deliver what was required.
First, though I would reinforce the vlaue of ensuring your project manager have a clear understanding of the latest industry PMI templates and structure (PMBOK) and your organization should have a formalized project methodology that is fully utilized. You should have at least 50% of your project managers (PMs) within your organization be PMP certified. If you have low proportion of PMs with certification today, set a goal for the team to achieve step improvement through a robust training and certification program to move the needle. This will imbue an overall level of professionalism and technique within your PM organization that will be beneficial. The first foundational attributes of good PMs are discipline and structure. Having most, if not all, of your PM team familiar with the PMI will establish a common PM discipline and structure for your organization.
So, assuming you have in place a qualified PM team and a defined project methodology primarily based on the PMI structure, then we can focus on three key project management best practice areas. Note these best practice areas help mitigate the most common causes of project failures which include:
lack of sponsorship
inadequate team resources or skills
poor or ambiguous requirements or scope
new technology
incorrect development or integration approaches for the scope, scale, timeframe or type of project
inadequate testing or implementation preparation
poor design
As I mentioned in the Project Initiation best practices post, there is a key early gate that must be in place to ensure effective sponsorship, adequate resources, and proper project scope and definition. Most projects that fail (and remember, this is probably half of the projects you do), started to fail at the beginning. They were started without clear business ownership or decision-makers, or with a very broad or ambiguous description of delivery. or they were started when you were already over-committed, without senior business analysts or technology designers. Use this entry gate to ensure the effort is not just a waste of money, resource time, and business opportunity.
So assuming you have executed project initiation well, you should then leverage the following project management best practice techniques.
Effective definition, design and implementation approaches: Failure in these areas is often due to what I would call ‘beating around the bush’. In many projects, getting the real work done — well-defined requirements, the core engineering work, thorough testing is hard and takes real talent. Many teams just work on the edges and don’t tackle the tough stuff. I recommend ensuring that your project managers and design leads are up for tackling the tough stuff in a project and doing it as early as possible (not late in the cycle). And when it is done, it should be done fully. So, some examples:
if requirements are complex and ambiguous at the start, a good project manager will schedule rigorous project definition sessions. The PM will ensure broad participation, and good attendance and engagement at the meetings. Perhaps even a form of Rapid Requirements is used to quickly elicit the definitions needed. Or, the project team will use an agile or highly iterative incremental approach to take back to the user interfaces and outputs for early clarification and verification.
if new technology is being used, or there is a critical component or algorithm that must be engineered and implemented, then work begins early on these core sections. A good PM knows you do not leave the tough stuff to be done last. In particular, these means you do not wait for the final weeks of the project to do complex integration. Instead you develop and test the integration early with stubbed out pieces. Pilot and test, if necessary in parallel, the tough stuff. And if there are major hurdles not anticipated, then you will find them out early and you can kill or alter the project much earlier with far less sunk costs.
as CIO, make sure that major IT initiatives that your company is investing in make a difference where the rubber meets the road. The system must be easier to do the most common tasks, not just lots of features and cool. You want to make sure the front line staff will want to use the new system (not be forced to convert).
in sum, the approach for the design and implementation work should be incremental, parallelized and iterative rather than serial, waterfall, or as I like to call it, ‘ big bang theory’. Waterfall can be used for well known domains, well understood engineering, and short or mid-range timelines. Otherwise, it should be avoided.
Project checklists, inspections and assessment: Use lightweight project and deliverable review approaches to identify issues early and enable correction. Given the failure rate on projects is typically 50% or more, and given the over-demand on most IT shops, nearly every project will have issues. The key is to detect the issues early enough so they can be remedied and the project can be brought back on track. I have always been stunned at how many projects, especially large ones, go off track, continue to be reported green while everyone on the project team thinks things are going wrong, and only at the very last minute do they go from green to red. Good quick assessments of projects can be done frequently and easily and enable critical early identification of issues. These assessments will only work if there is an environment where it is okay to point out issues that must be addressed. (By the way, if 90%+ of your projects are green, that means either no one can report issues or you have an extremely good project team). The assessments can be a checklist or a quick but thorough review by experienced PMs, issues should be noted as potential problems, and they are compiled and left with the PM and the sponsors to sort through and decide if and how to address them. Your senior manager in charge of your PMs and you should get a monthly summary of the assessments done. Often you will find the same common issues across projects (e.g. resource constraints or late sponsor sign off on requirements) and you can use this to remedy the root cause.
Another key technique to use in addition to project assessments is inspections. Just about any deliverable for a project, requirements, high level design configurations, test plans, can be inspected — not just code. And inspections are an under-utilised yet typically, the most effective way to find defects (other than production). Have your project teams use inspections for critical deliverables. They work. And augment inspections with a few deep dives (not inspections) of your own of both in flight and completed projects to ensure you have a pulse on how the work is getting done and what issues your teams are facing.
I hope to add some Project Assessment Checklists to the best practice pages in the coming month. Anything you would add to the list?
Next week I hope to tackle Program Management and Release Management and key best practices in those areas.
Any good project stories you would like to share? Anything you would change in what I recommended? Let me know.
Just as I published a quick checklist for you to use as the year was closing, here is a checklist for your first week back to help you get off to a great start of the new year. Plus, this is a lot more fun than taking down those outdoor Christmas decorations or doing returns of the unwanted gifts. So before the office gets busy, use your first few weeks to get a jump on outstanding results in 2012 with this list:
1. Remember to get the things done we planned in December. You have booked time in January with your team to do the detailed planning to ensure you have the IT goals for 2012 clearly defined with the key steps to get there. Knock it out with your team.
2. Set your 1st and 2nd quarter virtualization goals for your server and storage and sit down with them and ensure they are mapping out how to get it done. Get them off to a quick start.
3. Pick one or two major contracts to renegotiate in your favor this quarter. A quick hint: Oracle missed expectations last quarter so you may have an opportunity. Remember to hold tight, put something new on the table to get the most out of a deal, and insist on your terms and conditions (and if your company does not have an up-to-date contract template, put that on the plate with your Chief Procurement Officer to get it done).
4. Take those new insights that you gained from your holiday vacation (remember you were going to spend part of your vacation time reading a good management or IT book) and ensure you bring the view to your planning meeting.
5. Review your January schedule and ensure you have time with your customers fully scheduled. Invite one of them to kick off your planning meeting.
6. Also review the planning meeting agenda with your boss and ensure you capture any ‘messages’ he/she wants to make sure come across.
7. Sit down with the intranet team and ensure they are adding 1 or 2 helpful ‘widgets’ a quarter to your intranet site. Start with a ‘How do I …’ list button or improved search tool, or a wikipedia for corporate terms and abbreviations. The little helpful things mean a lot to the productivity of your company’s employees.
8. If you don’t have BYOD yet, sit down with your client device team and review the plans to pilot and then implement it this year.
9. Schedule a visit for you and several of your team to review either a customer facing site (call center or retail store) or a key operations facility for your company. Ask questions and see how IT is working where the rubber meets the road in your firm. I am certain you will learn plenty.
10. Review and report on your performance for the past year – do it with thought and be provocative. Challenge yourself and your team where you have not delivered well. Then follow up with a high level and positive note to your entire team talking in broad strokes about the goals for the year. Strong communication at the start of the year will help ensure you and your team are lined up for success throughout the year.
Many of these items are reconnecting activities: with your business, with your customers, with your boss, and with your team. Before you start off on any major endeavor, it is critical to recheck the plan and the communication lines — that is in essence what we are doing. And with it you will be much more likely to have a successful and rewarding 2012.
Project delivery is one of the critical services that IT provides. Unfortunately, in the industry, the track record of project delivery for IT is at best a mixed bag. A number of different studies over the past five years put the industry success rate below 50%. A good reference in fact is the Dr. Dobbs site where a 2010 survey found project success rates to be:
Ad-hoc projects: 49% are successful, 37% are challenged, and 14% are failures.
Iterative projects: 61% are successful, 28% are challenged, and 11% are failures.
Agile projects: 60% are successful, 28% are challenged, and 12% are failures.
Traditional projects: 47% are successful, 36% are challenged, and 17% are failures.
So, obviously not a stellar track record in the industry. And while you may feel that you a doing a good job of project delivery, typically this means the most visible projects are doing okay or even good, but there are issues elsewhere. In this post and in the next few I will provide a quick primer to check and ensure you are leveraging the key project delivery best practices that enable more successful track record.
Key project delivery practice areas: These areas are project initiation, project communications and reporting, project management, release management, and program management. There are also a few critical techniques to overcome obstacles including how to get the right resource mix, doing the tough stuff first, and when to use a waterfall approach versus incremental or agile. I will cover the first two areas today and the rest over the few weeks.
Project Initiation – I have rarely, and I suspect similarly for you, been part of an organization where the demand for IT to deliver projects is less than the supply of IT resources to execute those projects. In fact, this over-demand is often chronic and our IT response sometimes exacerbates the situation. Because of our desire to meet the business’s wishes, and to show progress, we make the mistake of initiating projects before they or our teams are ready to start. It is critical to ensure that you have effective sponsorship, a good bead on requirements and adequate resources before you initiate the project. There is no issue with doing concept or project exploration, initial requirements and designs, high level planning or estimation, but these must all be divided from the formal project effort with a strong entry gate that ensures you have the sponsorship, understanding of the deliverable, and adequate resources. Most projects that fail (and remember, this is probably half of the projects you do), started to fail at the beginning. They were started without clear business ownership or decision-makers, or with a very broad or ambiguous description of delivery. or they were started when you were already over-committed, without senior business analysts or technology designers. This is just a waste of money, resource time, and business opportunity.
Address this by setting a robust entry gate and be disciplined about when to start a project. If the business sponsors aren’t there, this is a discussion for you to have with that business leader. If the project is defined as overly broad or is ambiguous, don’t fall into that trap. Take the two or three most well-defined needs and split off or chunk the project into starting with just that piece. The rest will fall into place as the work is done and everyone understands better the situation. You and the business may decide not to progress further, If you decide to proceed then start up the next chunk as a separate project. And, as much as you want to get more done, don’t start the project before you have resources. As you operate your project ‘factory’ at extremely high utilization levels, each additional piece of work you add makes you less efficient and more costly. You must use higher priced contractors rather than internal resources. And your key experts that must do the work, now have to juggle one more thing and will be less effective. It would be far better for your 500 resource team to do say, 80 projects effectively, rather than 110 projects ineffectively. It is like a server that has not enough memory for the applications active on the system. More and more time is spent on overhead, paging things in and out rather than on real work. The end result is less work done in total even though more projects are active. This is a common trap that is overcome by knowing you effectiveness range and then simply prioritizing with the business. If something critical has come up then for it to be started you must ice and take off the table other projects. Make these choices with your business partners. If you maintain this balance, then you will get more projects done in the year — and that should be the true measure of delivery (not how man projects you started).
Project reporting and communication – Doing a project is a team effort. You have many staff with different backgrounds and skills from different organizations that must come together to deliver on a single blueprint to a common goal. With such a diverse team, effective communications are paramount. And yet, often, the only formal communications are those that a directed towards senior management. There are three primary audiences that a project manager should communicate formally: senior management, the business customer, and the project team. Further, the project manager should leverage the same detailed reporting and advanced analysis that they are doing to manage the project to quickly reformat into a digestible report for their audience.
Oftentimes, you find the project managers are burdened by multiple reporting systems where they are manually entering the same information two or three times. And then middle management for both IT and the business demand additional reports on metrics that are not useful and forms for approval that are bureaucratic and repetitive. Meanwhile, the critical data (e.g. risk items, resource utilization, critical path delays) are not reported broadly if at all. And the project manager is overwhelmed with the busy work versus the real task at hand.
So streamline the reporting process. Ensure your team a single, effective project reporting tool and invest in one if not. I recommend that all the but the smallest projects produce a weekly ‘4-Box’ report. This one pager can be used for all three primary audiences and ensures the project manager, the sponsor and the key stakeholders are paying attention to the important aspects of the project.
I will be placing a 4-Box sample on the reference page for your use later this month. But they key components are simple:
a landscape page with 4 quadrants, a left margin column and a header section
the header consists of the Project Title centered and Project Status in color boxes on the far right upper corner, and the project mission in small font (it always amazing how many people work on a project and do not know what it is intended to do — thus the mission on every communication)
the left margin contains the names and phone numbers of the project manager, sponsor, and all key participants and stakeholders. Thus everyone knows who to call if there is an issue or question
The upper left quadrant contains a brief description and the key milestones for the project with dates and a status indicator (e.g. completed, underway, etc)
The lower left quadrant box contains accomplishments and progress for the past week (or time period). There should be a brief description of progress and a listing of the key milestones or tasks completed.
The upper right quadrant is a listing of the key risks and issues the project faces. They should be catalogued and a status indicated (e.g. Mitigated, Underway, Open) with a color status as well.
The bottom right quadrant should provide what will will get done this next week or time period by milestone or significant task with dates and with owners.
Additional information can be used to augment the report, but they key is now you can use the same one page to communicate effectively with all your audiences. This ensures everyone is one the same page (literally) at a minimum of effort. Note also that we avoid the ‘ creative writing’ of project status reports that some many organizations waste time and use to put an optimistic spin on the project progress. Instead, just the facts.
By aligning your project process and teams to these two best practice approaches, you will find:
you are not starting projects before they are ready to be started
you will run your project factory at optimal output and effectiveness
you will lighten the overhead load on your project managers, so they can do more real work
your project teams will be on the same page (and thus more effective)
you and your businesses will know what is going on and can identify issues much earlier and solve them more quickly
In essence, you will deliver projects more successfully.
What are the variations on these approaches that you have used with success? What would you do differently? What other areas of project delivery are problematic that you have solutions for? Have a wonderful holiday and I look forward to your perspectives.
There was a very good article in the Wall Street Journal yesterday on ‘How to Save an Unproductive Day in 25 Minutes’. I found it useful that the article points out a few techniques to keep that day from being a complete loss. But while the authors pointed out a portion of the cause of unproductivity (fragmentation and interruption), they failed to really pin down why so many of us struggle to be productive at work. Or perhaps to put it another way, why so many of us spend nearly all of our time killing alligators and spend so little time draining the swamp. This tendency of being ‘too busy to be productive’ finds particularly fertile ground in IT organizations.
The reason this is more prevalent in IT teams is because in IT there are are the usual ‘urgent’ distractions of email and phone calls and business meetings AND there are additional and very real urgent distractions of production issues and high priority projects that are running late but must be completed on a specific date. Thus, the opportunity and time to do important foundational tasks is even smaller. As a result, I come across many IT teams that are running at 100 miles an hour, not doing a good job of delivery of production or projects and their teams are at or close to burnout. And yet the solution to this very real and overwhelming issue is close at hand for IT leadership to leverage.
To solve this ‘too busy to be productive’ issue, you must address it on two levels: for your self and for your team. If you are running around with your hair on fire, then no amount of coaching by you will change how your team approaches their work. Let’s start with the knowledge that we will be able to change both your productivity and your team’s dramatically in two to three months. Understand that going forward, things that are important (and may or may not have a critical time deadline) will take precedence over everything that tends to interrupt but is not important. And you must demonstrate this improved choice everyday for the next 3 months. Here are the steps to get you and your team out of burnout and delivering with much greater quality and capability:
For you:
a) First, get your calendar balanced. Take your calendar for the next two months and let’s implement some radical changes. First go through your calendar and categorize your activities as either important or not important, reactive (dealing with a crisis demand or the fallout of an issue) or proactive (e.g. planning or addressing root causes). After categorizing, it would be interesting to see how much time you are spending on important and proactive work. My bet is it is less than 25%. And it is even less than that because the first part of the meeting focuses on today’s production failure rather than the planning work you were going to do. Next, either delegate or eliminate all the not important meetings from your calendar. Then, at least 3 times a week allocate 2 hours for important proactive work. Ensure you cover the areas you know need the most attention. If production is a problem, then spend two hours on root cause and how to improve change quality. If project delivery is a problem, spend an hour with your key team reviewing your project metrics and constraints affecting delivery and how to solve them. Spend at least 1 hour per week ensuring your key goals for the next 3 months and the next year are clear, and craft the messages to ensure they are well-communicated. Spend another hour figuring out how you can improve or coach your team to better performance. And stop doing every email and phone call that comes in. You do not need to meet with vendors for new products and solutions when you are having issues with your current delivery. At least half of your emails never need to be read or responded to – ignore them. Stop interrupting your meetings due to phone calls unless it is your boss or a very important customer. Throughout your day, continually evaluate if you are spending good, solid time on important proactive work.
b) Make clear decisions and ensure you empower the team to execute with quality. Sometimes the cause of the productivity issue is a team caught up in over-analysis. If you are not making clear decisions or if you are making micro-decisions then you can cause your team to do 200% of the work necessary as they try to buttress their recommendation and collect every data point possible. Or the team may abdicate doing work they should do because in the end, they know that you will overrule them and make a micro-decision. Be self aware enough that you are causing these effects. If, in the past three months you have either recalled previous decisions more than once or sent multiple decisions back for more research than either the team is inadequate or you are not decisioning effectively. Sound out with a trusted colleague or coach if you need to improve your decisioning process. The bottom line is that you must stop requiring or doing unimportant analysis work or decision work. Let your team make the decisions for the areas they are accountable for and stop requiring perfect facts to make a decision in this imperfect world.
For your team:
a) First, set goals and expectations that i) you want them to deliver with quality and ii) you will support them to fix things so their work can be done in an improved manner. You must let them know that not only is it ‘safe’ to do things with quality, it is expected. Your team and organization may have fallen into the trap of thinking the only thing that is important is that work must get done based on the timeline, even if it means slamming something in that is riddled with defects. By insisting on quality first, you put your team on notice that this is foundational. Now, it should also be noted that this is not a pass to then have endless delays and no accountability to deliver. Instead, you must work hard to deliver in as timely a manner possible, but with the quality.
b) Use the proactive important time or your calendar to work with your team on the things that will improve how the work is getting done. Are your processes convoluted and time-consuming? Then spend time with the team to straighten them out and lighten the load. Are the tools inadequate? Then figure out what is best practice and pilot an improved set. Are things going in with lousy quality and causing production issues and lots of rework? Then stop letting poor quality change in and fix it before production. Do this even if it means a train wreck on a promised implementation date with the customer. Go and personally talk to the customer that quality is too important to you and to him or her. (I have never met a customer who remembered they insisted something go into production when it was known poor quality and instead blamed IT. Conversely, if you delayed something by a few weeks or even months yet it went in with quality, 6 months later, they invariably remember the successful launch versus the delay.) Spend your time with your team draining the swamp.
c) Set their goals and their schedule leveraging the fact the people do urgent things first. In other words, it is a natural tendency to focus on the urgent things like email instead of getting a backout plan done for a change or mapping out how we improve our development process. So, as the leader, set clear deliverables and clear dates and accountability for the important things (thus making the important and proactive work important AND urgent) for your team. It is a very effective management technique. Then, you will find that much more of the proactive work will get done.
Watch what happens then as a virtuous cycle takes hold. Because implementations start to get done with more quality, there is less fallout and production incidents. With reduced demand to work production issues, your team should have more time and focus on doing more proactive work (you must do (c) above to get this effect, otherwise they will just do more email or other urgent and unimportant work). And as they do more proactive work, they eliminate bottlenecks and rework and become even more productive. This cycle will take a few months to gain traction. And if your organization is really in a rut it may take as long as 6 months to show measurable difference. But usually, the effect is much quicker, and the first lift can be outpaced by the second and third and subsequent lifts as the cycle repeats. I recall one infrastructure component team that had a terrible production track record, the rest of IT viewed them as a bottleneck in the project process and the team, being close to burnout, saw no solution except to double or triple the number of staff. By implementing this approach, within a few months their change success rate went from the mid eighties to better then 99% and they trimmed their implementation processes significantly in terms of effort to deliver a unit of work. Everyone understood what their goals were and what was important to get done to be successful. And when I asked one of the managers to compare his team’s work to the state three months prior, he said ‘It is night and day. I can get all the important work done and our implementations go smoothly. I no longer spend every evening on a bridge call trying to figure out why something is not working. And I come in the next morning refreshed and productive. My week is in a box.’ This was the result in just a few months.
It can be tough in IT with the press of production incidents and the pressure of critical project deadlines. Add to that our everyday distractions of email and mobile devices and trying to keep up with the pace of technology and we soon lose the forest for the trees. Perhaps the best treatise on this effect is in ‘The Seven Habits of Highly Effective People’ by Stephen R. Covey and his time management matrix. By leveraging this knowledge of techniques to ensure we work on the important things versus the unimportant but urgent, you can be a better manager and your teams can be more successful and have their week in a box. You might even buy copies of this book for your managers so they understand what is happening themselves and learn personal techniques to address it.
All of us undoubtably, have had some experience where we felt trapped in an overwhelming level of work and no real way out. How did you solve this? Do these approaches resonate with you? Have you employed them to change your team in a sustaining way? I look forward to hearing from you.
In the last several posts we have covered how you should deliver IT cost reductions with long term tactics that also enable you to build capability and capacity. If executed well, you will also yield some longer term benefits such as a better workforce balance or elimination of redundant or low value systems. These tactics require relentless leadership and focus by you. You must keep them in the forefront and ensure you are progressing on them everyday. Your patience and influence are required as well. You must obtain business support for efforts that often have a longer cycle than the business team is used to supporting. If you are both consistent and persistent in your approach, and employ these tactics, you will make a material difference, in some cases a massive difference, that will make your business far more competitive and is simply unattainable through other approaches.
We discussed that these long term tactics are executed by first laying a groundwork for sustainable improved cost through quality. Second, you build a highly productive and well-balanced team in order to meet a world class cost profile. Throughout you leverage metrics-based, transparent framework with continuous process improvement that enables you to progress and achieve world class performance. A concurrent effort with building a high performing team is to migrate to a modern, consolidated infrastructure and well-architected core systems. We will discuss this effort today and wrap up our efficiency discussion.
Nearly every IT shop that has quality or cost problems has a proliferation of archaic systems and fragmented, legacy infrastructure. The causes of this are myriad but generally result from: poor or shifting business vision and sponsorship (e.g., when you have 3 different sales executives in 4 years, IT delivers 2 and 1/2 application systems trying to match the business variances and results in multiple systems that never do what was needed); an inability of the business to invest in a steadfast manner (e.g., IT projects run out of funding, or funding shifts, thus every year projects are half completed resulting in the old systems staying in place with the new systems going in); a stagnant IT team with poor best practices and leadership that allow multiple mediocre solutions where one good solution would suffice.
As the IT leader, you must tackle the business causes first before setting out to fix this area. Draw up a compelling vision of what the systems should provide. Research and gather the facts on the costs, time to market impacts, business productivity, feature loss and quality issues due to the current multiple mediocre systems. Map out a new process and authorization where you get the multi-year business support and sponsorship to execute the vision. Going from three mediocre overlapping business systems to one well architected systems with better quality will enable efficiency and productivity gains across the board — in your shop and in theirs. This is a vision that you should get everyone to rally around. Ensure there is a investment process that enable multiyear funding and review of major projects and conversions that also tracks to ensure the benefits are delivered. The CFO should be your partner in this. It is in his interest to see that everyone meets the costs reductions and other benefits promised. And it is in yours as well, because often you accumulate the layers of barnacles by only doing 80 or 90% of a project and not doing the final steps of decommissioning the old systems. By having a multi-year project process with benefit review or scorecarding in place, there will be far more impetus to ensure projects are completed and old systems removed.
Assuming you address the business sponsorship and project process issues, you must also address poor leadership and implementation on your side. First and foremost, IT cannot be a place for ‘hobbies’. That is, you need to ensure that all those pet technology projects and explorations that are not absolutely critical to a business capability or technology implementation that has real, near term benefits, are killed. Otherwise, they are a distraction and a multiplication of your technologies and thus costs.
Second, require every major application area and infrastructure component to map out current world and a future world where they are consolidated and at best practice. Then sit down with each team and your architectures and lay out the trajectory to get from today to best practice. Estimate the benefits from the transition. Ensure you capture the gains from your productivity and quality improvements. Then pick the top 3 to 5 areas and target them as major transformation initiatives for investment and turnaround. Garner the business support, get the approvals, make it part of your IT goals and communicate the importance to your team. And of course execute them. But also, in the other areas that mapped out their trajectories, work with them to come up with ways to make progress without major funding. Identify and execute the quick ROI projects that enable you to save within the year or almost within the year. Work with vendors to come up with creative ways to overcome the investment hurdle to move your technology to a best in class platform. And every time you can come up with efficiencies or savings elsewhere, turn around, pull the next best consolidation and replatforming project off the queue and get it going. As these projects execute and land, it will drive a virtuous cycle of additional savings and quality that will enable you to more rapidly transform as well as to shift, over time, more and more resources to the point of the spear where you are attacking the business problems and needs.
The long term tactics will take 9 to 12 months to achieve some results and 18 to 24 months to yield impacts, but once you really start executing and implementing, the compound gains can be enormous. Given IT can be a very large cost center within a corporation, IT can often one of the top contributors to cost reductions. And given IT systems availability and quality drive customer service, IT improvements can be the biggest push behind improved customer satisfaction. These are huge wins for you company. So, as you are faced with cost efficiencies demands of todays environment, leverage the near term and long term tactics described to put you and your company in a winning position.
So, we have spent nearly two months covering the very important topic of cost efficiency in IT. Every IT shop today is faced with these demands. You now have the tools to drive this far more effectively. Let me know where things have gone awry or where more detail is need to handle the complexity of your situation.
