You are currently browsing the monthly archive for December 2008.
Fast away the old year passes. It’s time for New Year’s Resolutions. Even if you’re not a resolution-making sort of person, the additional challenges the economy imposes on the coming year make it absolutely essential to think through some changes in approach.
Budgets will be tighter, and in the grand tradition of good things that roll downhill, the people who will most feel the squeeze are the people in charge where the rubber meets the road, the project managers. You will be challenged to do more with less, to face multiple changes in strategy and scope, and to achieve success on tighter timelines.
Here are some suggestions for thinking outside the box in 2009:
Manage your team, not your project plan. Your project plan file is merely a tool for planning and tracking. The key to success is your daily leadership of your team. Meet frequently with each contributor to your plan to understand where their difficulties are and to suggest tactics for moving past bottlenecks. This is much more valuable to the project than reporting that task 345 is only 45% complete as of the end of the week. This leads to the next resolution, which is:
Embrace collaboration tools aggressively.New times and new challenges call for new tools. Use project portals to the fullest. Get beyond Level 1 portal usage (shared documents) and fully exploit the discussion and alerts features. Build status dashboards for your executive sponsors, so that status communication becomes more than a once a week meeting or conference call. With widely dispersed teams becoming more the norm than the exception, twitter-like tools can help project managers to keep tabs on the current activities of all team members, and foster real-time assistance when team members tweet about a newly encountered difficulty.
Slim down that project plan! You just knew there had to be a diet resolution in here somewhere… Your plan needs only enough detail to quantify effort, predict duration, and define a critical path. More detail beyond that means more overhead in terms of status tracking and replanning, and if this is not in the project budget, it’s only going to come out of your personal time.
Build contingency plans into your approach from Day 1. All that stuff about completing projects on time and within budget as the measures of project success is very pie-in-the-sky. There will be changes in scope. There may be changes in budget before you get to the build phase. The key milestone date may well be pushed up while you are still in the analysis phase. Have a clear idea of what’s essential for launch and what can be deferred from Day 1 and you will be in better shape to roll with the changes.
Align effort with risk. Don’t spend 80% of the analysis effort on 20% of the business functional domain, unless that 20% is the most mission critical, the most regulated, or the most central to driving revenue. As the project manager, you must rein in project team members who are focusing on areas that are not really central to the success of the effort. In this new tighter budget, compressed timeline world, there are going to be some bumps in the road. You need to make sure that mission critical requirements are safeguarded at the expense of those business requirements that are less crucial from a bottom line perspective.
Start with Data Quality
Many organizations are currently working on Master Data Management (MDM) strategies as a core IT initiative. One of the fastest paths to failure for these large, multiyear initiatives is to ignore the quality of the data. This is a good post on other MDM design pitfalls.
Master Data Management (MDM) is defined as the centralization or single view of X (Customer, Product or other reference data) in an enterprise. Wikipedia says: “master data management (MDM) comprises a set of processes and tools that consistently defines and manages non-transactional data entities of an organization (also called reference data).” MDM typically is a large, multiyear initiative with significant investments in tools, with two to five times the investment in labor or services to enable the integration of subscribing and consuming systems. For many companies you are talking millions of dollars over the course of the implementation. According to Forrester, on average, cross-enterprise implementations range anywhere from $500K to $2 million and professional services costs are usually two dollars for every dollar of software license costs. When you consider integration of all your systems for bi-directional synchronization for customer or product information, the services investment over time can be up to five times the license cost.
At its simplest level, MDM is like a centralized data pump or the heart of your customer or product data (the most popular implementations). But once you hook this pump up, if you haven’t taken care of the quality of the data first, what have you done? You have just spent millions of dollars in tools and effort to pollute the quality of data across the entire organization.
Unless you profile the systems to be integrated, the quality of the data is impossible to quantify. The analysts who work with the data in a particular system have an idea of what areas are suspect (e.g., “we don’t put much weight in the forecast of X because we know the data is sourced from our legacy distribution system which has data ‘problems’ or ‘inconsistencies’”). The problem is that the issues are known at the subconscious level but are never quantified, which means a business case to fix the issues never materializes or gets funding to make improvements. In many cases, the business is not aware there is a problem until they try to mine a data source for business intelligence.
According to a study by the Standish Group, 83% of data integration/migration projects fail or overrun substantially due to a lack of understanding of the data and its quality. Anyone ever work on a data integration project or data mart or data warehouse that ran long? I have, and I’m sure most of the people reading this have too.
The good news is that data profiling and analyzing is a small step you can undertake now to prepare and position yourself for the larger MDM effort. With the right tools, you can assess the quality of the data in your most important data sources in as little as three weeks depending upon the number of tables and attributes. Further, it is an inexpensive way to ensure that you are laying the foundation for your MDM or Business Intelligence initiatives. It is much more expensive to uncover your data quality problems in user acceptance testing. Many times it is fatal.
Success of your MDM initiative depends on the quality of the data – you can profile and quantify your data quality issues now to proactively head off problems down the road and build a business case to implement improvement in your existing data assets (marts, warehouses and transactional systems). The byproduct of this analysis is that you can improve the quality of the business intelligence derived from these systems and help the business make better decisions with accurate information.
…Is that it arrives before we are ready for it.” A bit of plainspoken wisdom from American humorist Arnold H. Glasow. Thanks to the miracle of google, it becomes our intro quote for today’s topic of acquisition integration readiness.
In an earlier post, we talked about data integration readiness, but that’s only one task on a list of things you should be doing now if you plan to acquire a company in 09. Readiness is the word of the day, and the best way to sum it up is you have to have a documented platform to integrate with across the board, or you will lose time during your integration period. Lost time means revenue drag–you won’t hit your projections.
So, let’s make a list.
1. Data integration readiness, already covered in detail here.
2. Process readiness – are your procedures for key business areas up to date? You will need to walk through them with business team leads on the acquisition side to rapidly understand the gaps between the way they do business and the way you do business. Can you rapidly train the influx of people you will be onboarding with the acquisition? An effective training plan is a solid way to minimize post-close chaos.
3. Collaboration readiness – don’t underestimate the amount of time those new employees will take up with endless “How do I?” questions. Hopefully, you have a corporate knowledge portal in place already and you can give them access and a navigation walkthrough on Day 1. Make sure it includes discussion groups, so that the answers to their common questions can be searchable and institutionalized. There was a great post on this recently describing how IBM is using collaboration tools to help with acquisitions, and Edgewater’s Ori Fishler and Peter Mularien have posted extensively on Web 2.0 tools for corporate collaboration.
While we are on the subject of collaboration tools, let me tip you off to an important secondary benefit. The people that use them and participate actively in discussions are your change agents, the people that can help lead the rest of the acquired workforce through the integration. The people that don’t participate, well, they are your change resistors. They need to be watched, because they may have emotionally detached from this whole acquisition thing. If they are key employees, you want to make sure they don’t have one foot out the door.
4. System integration readiness – It’s oh-so-much-more-challenging (meaning time consuming and costly) to integrate into an undocumented or underdocumented architecture. Get your data flow diagrams and infrastructure diagrams, as well as your hardware and software inventories up to date before you close.
That first quarter after you close will still be a wild ride, but you can be sure you’ve cut the stress level down significantly if you make these readiness tasks a priority before closing day.
(Wouldn’t It Be Nice If…)
Wouldn’t it be nice if vendor product administration systems could be configured to your exact specifications, screen designs, workflow, automation, and include flick of a switch integration. Wouldn’t it be nice if the system was intuitive enough to know that most of your business uses the same forms, limits, and deductibles, except in a small number of cases. Wouldn’t it be nice if the implementation was as easy as installing music software and you only have to run the setup.exe file and you’re ready to start writing business or administering claims.
That would be nice. But its not realistic. Implementing a new system to support your business is laborious and requires the proper attention by the proper people; otherwise, garbage in – garbage out. Underwriters, Claim Managers, Agent Relations people, don’t want to deal with putting in a new system, they just want the system in and working. But what does “in and working” mean? Many companies often do not recognize the magnitude of what they are undertaking. They go through the process of selecting an off-the-shelf product and believe this is what they really want. “This works for us and we can move forward with this.” Most of the time, that’s true. Unfortunately, most of the time its also true that the business then decides that there are many shortcomings in the new system and wants to reinvent it using five simple words: “Wouldn’t it be nice if…”, and IT must respond. This starts the snowball down Customization Mountain and before anyone realizes, the requests for changes are so frequent, and often so unnecessary, the hopes of what will be in production are unrealistic. The pedestal upon which the system has been placed is so high, it cannot be reached.
Wouldn’t it be nice if the user could put on a helmet, and the system could read their thoughts to enter the data and move through the system. Just like Clint Eastwood flying the Russian aircraft in the movie Firefox.
But what are the reasons for some of these changes? Why does the business need so much customization for a system they spent so much time and money selecting? When asked these questions, often the business response is, “Because that’s what we do now.” Doesn’t that defeat the purpose of implementing a new system if you just want to keep doing what you’re already doing? That’s like buying a new horse to pull your trailer of goods, instead of a pickup truck. You’re not taking advantage of the features, functions, and new technology of the system, if you don’t also look at Business Process Adoption. Changing your business processes is most often much more cost effective than system customizations and will reap longer term benefits for the company. System changes increase maintenance time and costs with upgrades, not to mention being the major source of costs overruns and project delays.
Try to remember that vendors build systems to satisfy everyone; and you can’t satisfy everyone all the time. Go as close to the base product as possible, even putting that into production first, then look at making necessary changes. Your success rate will be much higher and your budget won’t get blown out of the water. Don’t try to rush everything into production on the first go-around. Take it in pieces and concentrate on delivering successfully using as much forward-thinking implementation as possible, such as using SOA in your existing architectures and platforms.
Then management will say: “Wasn’t it nice that the system went in on time and on budget.”
The Holidays are here and with them all the yearly summaries and forecasts. It may be a good idea to go back a year and check how many oracles have seen this slowdown coming..
As I look ahead to 2009, I see a few clear trends for web technology areas that are providing value in these rough economic times and are maturing to the point that companies cannot ignore anymore.
Gartner published their list of strategic technology trends for 2009 a few weeks back. They highlight Cloud Computing, Web Oriented Architecture, Enterprise Mashups and Social Software and Social Networking.
Here are 5 additional web technology trends that will be important in 2009, in no particular order:
- Actionable Web Analytics as part of Enterprise BI and Dashboards.
Web Analytics in many organizations is still an orphan with no real parents. Every department looks at its data but rarely does it get a strategic priority as an indicator of business trends and business intelligence asset. Investment in web analytics allows for customer insights, marketing spend ROI, conversion optimization and can impact the bottom line. As companies invest in sophisticated BI and analytical dashboards, web based data that is not transactional is usually not there. Integrating web traffic and user interest data into these systems can result in new insights and better actionable data. - Phone Browser Compatibility
Mobile computing is booming. About 13M iPhones were sold so far, and the support for location and browser that both the Android, Blackberry and all Microsoft based smartphones are offering, the percentage of traffic to web sites coming from phones is already in the 3%-10% range and will only increase. These are not the early 00’s WAP/WML jokes but full HTML browsers. Still, these special browsers are very different from the full version used on PC’s and Laptops. Bandwidth is still a challenge and their support for Rich Applications such as Flash and Silverlight is lacking. If you have a fancy Flash based site, your users will most likely not see a thing. Companies that have ignored it so far will have to adjust their sites or redirect mobile traffic to a mirror mobile optimized site. - Location based services
Continuing from the previous point, these mobile devices have GPS included and location based applications can drastically impact the user experience. Either as an iPhone/Android application or websites, the ability to share location information and get back location specific data about local services, other people, events, sales or anything else adds a new dimension to mobile applications. - Increased reliance on open source infrastructure products and technologies
Free is always a powerful word. Strong and reliable open source environments allow companies to create a robust e-commerce infrastructure with little or no proprietary platforms. The excellent Apache OFBiz for example, provides strong open source modules for e-commerce, ERP, CRM and many others. Alfresco offers a great content management solution and multiple open source development environments are available. The case for Enterprise Open Source web environment is getting stronger every day. - Approaching Social Networking and Collaboration in a Strategic way
Everyone now realizes the power of social networks and is rushing to get in, establish a FaceBook page, a Twitter account and get’s their PR to sprawl the web to “engage” people. Internally, companies are haphazardly trying various collaboration methods. We see a maturity process happening through 2009 that will force companies to look at all their collaboration points in a strategic way and tie them to business goals and processes. This new approach will transform them from toys to tools and will establish their place and value in the new order.
The Holidays are a great for watching “End of the World” shows on the History Channel. They were a great comfort, actually almost encouraging, because all of the prophecies target 2012. “The Bible Code II”, “The Mayan Prophecies”, and the Big 2012 Special compendium of End of the World scenarios, covering Nostrodamus to obscure German prophets, all agree that 2012 is the big one (Dec 21 to be exact!) What a relief!, the rest of the news reports are trending to canned goods, shotguns, and gold by the end of the year. We really have almost a whole 48 months before everything goes bang (I wasn’t ready anyway, procrastination rules!).
Unfortunately, we need to do some IT planning and budgeting for the new year and probably should have some thoughts going out 36 months (after that see the first paragraph). As I discussed in a prior blog, the reporting, BI/CPM/EPM, and analytics efforts are the strongest priority; followed by rational short cost savings efforts. All organizations must see where they are heading and keep as much water bailed out of the corporate boat as possible. Easy call, job done!
Then again a horrifying thought occurred to me, what if one of these initiatives should fail? (see my nightmares in prior blog posts on Data and Analytics). I am not saying I’m the Mad Hatter and the CEO is the Red Queen, but my head is feeling a bit loosely attached at the moment. Management cannot afford a failed project in this environment and neither can the CIO in any company (remember CIO=Career Is Over).
The best way to ensure sucessful project delivery (and guarantee my ringside lawn chair and six-pack at Armageddon in 2012) lies in building on best practice and solid technical architecture. For example, the most effective architecture is to use a layer of indirection between the CPM application (like Planning & Budgeting) and the source data systems (ERP, Custom transactional). This layer of indirection would be for data staging, allowing transfer to and from fixed layouts for simplified initial installation and maintenance. In addition, this staging area would be used for data cleansing and rationalization operations to prevent polluting CPM cubes with uncontrolled errors and changes. In terms of best practice, libraries and tools should be used in all circumstances to encapsulate knowlege rather than custom procedures or manual operations. Another best practice is to get procedural control of the Excel and Access jungle of wild and wooley data which stands ready to crash any implementation and cause failure and embarassment to the IT staff (and former CIO). When systems fail, it is usually a failure of confidence in the validity or timeliness of the information whether presented by dashboard or simple report.
CPM, EPM, and Analytics comprise and convey incredibly refined information and decisions of significant consequence are being made within organizations to restructure and invest based on this information. The information and decisions are only as good as the underlying data going into them. So skimping on the proper implementation can put the CIO’s paycheck at serious risk (Ouch!).
