Building Analytic Components, Part 2

In the previous article we discussed the big picture process of developing analytic components, and we introduced the example we will build on moving forward, which will be drawn from an examination of the data available to review and manage IT Portfolios within the Federal government. The example is enormously relevant because of the challenge of developing useful reporting based on the existing data, which is focused on supporting citizens in understanding the execution of government spending, but may not be as useful for government folks in understanding their own portfolios. This is very similar to the issues most developers of analytic components will face within their own organizations. We are often forced to make a first iteration that “proves the point” with data that was developed for some other purpose or which isn’t a perfect match for our analytic purpose. Often in the pursuit of better organizational performance we are trying to glue different types of data together to provide some previously uncovered insight that drives improvement. Almost inevitably our effort will run into issues with data because we are developing things for a specific purpose, which had gone un-measured until we discovered that new purpose. Maybe we need additional financial data from the accounting department on purchasing of technology to marry to performance information from the IT Operations organization. It may be that the purchasing information as it stands is not granular enough for our final purposes now, but if we build our mockup and business case well enough we may be able to persuade all parties that gathering that information would bring real value to our decision making. 
In our current example, the challenge will be to develop something more meaningful for government decision makers based on the data that is currently available, as well as to develop a “wish list” of information we will need to better facilitate the decision-making process. Some of this information is completely aspirational, and some may be as simple as querying the internal systems and reports that are not publically available but that we know are tracked. For example, we know that project execution data within individual investments is tracked in detail within the OMB 300b; while this information is not publically available and therefore not going to make our initial live analytic components, we can assume it is available for future reporting should our IT investment manager require it. To the degree possible, I try to find the balance between what I can show now to make the data and benefits real for a client, and not constraining the total possible value proposition too much by ruling out data that is not immediately available. In this case we are working to better enable our government IT investment manager to better manage the portfolio and improve organizational performance. In order to keep the size of this article reasonable we are going to constrain our hypothetical IT investment manager to only three high level goals: 
  1. Look at their IT portfolio and identify investments that may be at risk or that may require intervention. 
  2. Look for opportunities for collaboration and attempt to identify redundancy in the portfolio. 
  3. Identify data quality issues, process issues, or other factors that may be impacting the performance of the portfolio.

Identifying Investments at Risk 

Our IT investment manager may first want to look at the portfolio from the standpoint of understanding which investments might be at risk. In order to do this we need to be able to understand the factors that may potentially impact investment performance. The following seem particularly useful and are available from the IT spending dashboard: Variance from Schedule: Are we ahead or behind schedule? I would posit that too great a variance in either direction is probably bad. Even if you are ahead of schedule, it usually says something about your planning if you have too much variance. On the IT spending dashboard, variance greater than 30% is red, 10-30% is yellow, and less than 10% is green.

  • Variance from Cost: See above for the most part; variance of any kind isn’t great, but obviously most of the time you are less worried about being over budget than under. 
  • CIO Rating: This is a best-judgment measure that is supposed to roll together quite a few things into one simple rating, including: risk management, requirements management, contractor oversight, historical performance, human capital, and others. 
  • # of Baselines: The standard against which the performance of the work (in the context of cost and schedule) are measured. Understanding the baseline history places the variance from cost and schedule in context and provides insight into the planning and management of the IT investments. 
  • Size of the Investment: This is useful for prioritizing deviation from cost and schedule. In terms of identifying where to exert management influence first, the investment manager may want to understand the dollars involved. 
  • Performance Metrics: The specific metrics being used to measure investment performance as well as detailed attainment data. 

Things that might be helpful but which aren’t available from the dashboard:

  • Criticality of the investment: Every investment is important, but some are absolutely critical to the organizational mission. The IT spending dashboard lets us see what business function is being supported (BRM) and what services are being delivered (SRM), but doesn’t help us get to a value judgment on the criticality of the investment to that agency or its relationships with or influence on other investments. 
  • Internal/External Users: As above, there is precious little information that would help me determine how big the impact to organizational performance would be if there were problems with the investment. Understanding the size and scope of the user community may help us understand and evaluate the potential impact of investment risk. 
  • Organizational Desire for the Investment: I am trying to draw a line between criticality and desirability here. Criticality I am defining as the investment’s relationship to achieving the mission. Desirability may be something which takes performance from satisfying a requirement to exceeding a requirement. As part of our stakeholder analysis we put ourselves in the shoes of the IT Investment Portfolio Manager and came up with the following key criteria:
 Important Investment Factors

Purpose of the Analytic Component 

One of the hardest things to do when thinking about developing analytic components is develop the statement encapsulating the purpose of the analytic component. Our first analytic component for the investment portfolio manager (IPM) will be focused on helping guide the IPM’s eye to the investment that most require attention. This may be harder than it would seem. One of the hardest things I find in developing high-level dashboards is to resist the temptation to overcomplicate or try to service a broader audience than is really intended. Our dashboard is intended for the person in charge of managing the entire IT investment portfolio. As such, some detail that will be available from more analyst-oriented dashboards will either be abstracted or otherwise wrapped into the presentation layer. The design tension here – between giving enough detail to support decision making and presenting a very complex information set in a manner that is accessible – is going to be very difficult. Throughout the development of most analytic components we will identify measures and views that are very relevant to other stakeholders. In the case of this example we are going to find a great deal of information and views that will resonate with individual investment managers, project portfolio managers, project managers, and analysts. Keeping laser-focused on the objective of our high-level stakeholder will be critical to ensuring the eventual success of the dashboard. We may also need to build some of the lower level analytics in order to understand the various components of the high level analytic well enough to understand the interplay and relationships of the various components.
Stay focused on the right stakeholder group

Finding Value in the As-Is Analysis I mentioned in our first article that an early step in the building of analytic components is to start with what is currently in place. For our IPM this means looking at the existing IT Spending dashboard for ideas. In looking at the information available to us currently, I think that it is obvious that we need to address issues with investments that are ahead or behind schedule/cost or that have been flagged by the CIO. These are the “Big Three” on the existing IT Spending Dashboard and are represented as shown in the following:

IT Dashboard Big Three

Project Level Cost and Schedule Variance Rating
Evaluation (by agency CIO)
≥ 30%
1 (High Risk) or 2 (Moderately High Risk)
≥ 10% and < 30%
3 (Medium Risk)
< 10%
4 (Moderately Low Risk) or 5 (Low Risk)

The dashboard does provide the useful feature of enabling you to select whether to view the variance in terms of investment count or by dollars, but does not necessarily help me group or grade investments in order to ensure I give my attention to the ones that are most in need first. Because of this, I think one of the first things our investment manager needs is a way to combine these measures to get a reasonable sense of their impact on investment performance. A problem also exists when we dig deeper into the data, because the cost variance and schedule variance are being driven at the project level, which lives below the investment level. This creates a reporting problem because any specific project-level schedule or cost variance may have disproportionate impact to the overall execution of the investment. A critical path delay in a specific project may unleash a ripple effect of consequences that greatly exceed just the specific project impact; the reverse is true as well. We can certainly handle this from a detailed analysis level by providing a detailed project analysis dashboard depicting cost and schedule variance across the project portfolio. However, even here some real thought will be required in order to surface critical path projects that are at risk. For a large department with several hundred projects and billions of dollars in the portfolio, we need to develop an analytic component that provides a holistic view of our investments. The spread and number of the projects presents us with a problem as we try to look at our project portfolio for clues to our investments. If we use a four square chart showing project variance by cost on the y axis and project schedule variance on the x axis we can clearly identify projects that are in trouble, but it is hard to visually understand how this relates to my investments because there is not a clear way to group the projects and show a consolidated measurement of what this means for the containing investment. It would be much cleaner if the investment portfolio manager could look at the simpler investment only view.

Cost Variance and Schedule Variance Grid
Investment Portfolio
Project Portfolio

It is immediately apparent that the investment chart does not present the whole picture and that the project portfolio chart does not necessarily help the investment manager. In order to help our investment manager we are going to have to come up with some way of characterizing the project-related characteristics being carried within the investment that will help the investment manager identify trouble spots within the portfolio. It should be understood up front that this analysis will not replace open communication with individual investment managers in order to ensure that hidden threats do not turn into major problems. The purpose is to help the portfolio manager identify who to speak with first and direct the attention of the portfolio manager to the areas of the portfolio where attention is most needed. The following include some of the many strategies for enabling the ITPM to leverage the project related characteristics contained within the project portfolio that is attached to each investment:

  • Adding total variance from estimated cost and schedule: Characterizing the investment by total variance gives us a sense of how far off the plan we are, but not necessarily how far off track we are. For example, if we are way ahead of schedule and way behind on cost we may be poor planners, but we may not be in big trouble. 
  • Average into a score: Average all of the projects within an investment and score them on that basis, then characterize the investment in the same manner. This is essentially the same strategy that was used previously under the investment wide scoring process used until last year. The flaw of course is that it does not truly represent the cost and schedule risk in proportion to the dollars that comprised the project. 
  • Percentage of dollars at risk: Create a scoring system or other mechanism to categorize CV and SV into a way of putting it into buckets (R, Y, G). Essentially, size the projects by dollars, decide how what percentage of the investments total dollars need to be “at risk” to constitute an overall rating (R, Y, G) for the whole investment. 
  • Combined with Rules: Create a scoring system or other mechanism to categorize CV and SV into a way of putting it into the (R, Y, G) buckets. If any project is Red, the investment goes red. Outside of red, decide if the investments are green or yellow overall based on a simple majority of the dollars at risk. 

Depending on the organization, any of the above could work, and one of the nice things that would be possible with a strategy that enabled a real score based on project risk per investment is that it would allow us to rank our investments in order by our risk factors. This might be very helpful is we were to attempt to develop a scorecard and ranking system that included all of the above investments. However, that exercise will have to wait for another day. We want our portfolio manager to be able to view the IT investment portfolio and intuitively grasp which projects need the most attention. To do so we have narrowed our focus to a few critical categories of information and developed the following rough design:

Rough IT Investment Portfolio Design

We are going to use a TreeMap, which is useful for “displaying hierarchical (tree-structured) data as a set of nested rectangles. Each branch of the tree is given a rectangle, which is then tiled with smaller rectangles representing sub-branches. A leaf node’s rectangle has an area proportional to a specified dimension on the data. Often the leaf nodes are colored to show a separate dimension of the data.” (Wikipedia, 
By default, our treemap will depict the following: 
  • Dollars at Risk: Investment dollar value will be characterized by rectangle size, with their associated projects nested within them also shown by dollar size. 
  • CIO Rating: Each investment box will be colored Green, Yellow, or Red, based on CIO Rating. For an explanation of CIO rating, see 
  • Project Risk: Each project will be colored Green, Yellow, or Red, based on Cost Performance Index range. 

CPI essentially provides an indicator of how much you have accomplished of the plan based on the dollars expended against the plan. One of the most difficult decisions we made in developing this design was in trying to develop a method for characterizing and visualizing project related risk within the portfolio. We chose to use the cost performance index (CPI), which is described by Wikipedia as: 
“CPI greater than 1 is good (under budget): 
< 1 means that the cost of completing the work is higher than planned (bad); 
= 1 means that the cost of completing the work is right on plan (good); 
> 1 means that the cost of completing the work is less than planned (good or sometimes bad). 
Having a CPI that is very high (in some cases, very high is only 1.2) may mean that the plan was too conservative, and thus a very high number may in fact not be good, as the CPI is being measured against a poor baseline. Management or the customer may be upset with the planners as an overly conservative baseline ties up available funds for other purposes, and the baseline is also used for manpower planning.” (Wikipedia, 
The downside of this is that it is more geared toward financial performance than specific performance against the plan so our investment portfolio manager will not easily see important schedule lags for example, but we felt it was a good compromise. No dashboard will replace good communication, and critical path issues – including schedule lag or other issues bubbling out of the project portfolio – will still require excellent communications and further analysis. I’ll post the finished dashboard to the site next week. As always, I appreciate your feedback and look forward to continuing the discussion. Are you interested in learning more about the visual design of informational elements? Read”The Visual Display of Quantitative Information“to get the journey started.
Put our team to work improving your organization’s performance. 

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at

If you are interested in consulting services please go to MB&A Online to learn more.

Building Analytic Components, Part 1

Business Intelligence seems to be on the tips of many IT executives tongues these days. After the Cloud, Big Data, and Master Data Management; Business Intelligence has a prominent place in the pantheon of IT buzz words. The intent of business intelligence to me is quite simple, leverage the information available to the business to improve performance. This can take many forms, but at its core BI isn’t about making the dashboards, cool charts, or data warehouses. It is about helping the organization make better decisions. With that said I am going to walk through the process of designing a single business intelligence analysis component focused on IT Portfolio Management in two articles. The first article will describe the high level process of developing the analytic, and the second article will be a detailed dive into the development of a specific analytic component that will be used to manage investments within the portfolio. I will be using data from the Federal IT Spending dashboard which is publically available at Just because the data is from the public sector doesn’t make this example less relevant to the private sector.  IT investment portfolio characteristics like deviation from cost and schedule are broadly applicable across both the public and private sector, and the complex missions and comprehensive IT portfolios ofthe public sector can provide a rich point of reference particularly for very large (Fortune 500) private sector organizations.

Caption: IT Spending Dashboard
I think that with any analysis or reporting component it is important to start by identifying the stakeholder community that is being served. In this case, the analysis component under development will be used by IT Investment Managers and the senior executive team tasked with managing the organizational IT investment portfolio for performance and risk. In both the public and private sectors IT portfolio management is an often talked about but often difficult to execute practice. For large organizationsthe ability to manage competing organizational requirements, disparate technologies, uneven performance data, and complex portfolio composition issimply too difficult.  The portfolio ends up becoming largely managed on the basis of organizational politics and personalities. In order to effectively manage the IT investment portfolio of a large and complex organization there needs to be a data driven approach and analytics that are available and agreed upon by the entire organization. Developing these analytics and the comprehensive suite of informational requirements necessary to manage a complex organization required more space than I have in this article. My intent here is really to focus more on the process of tailoring analytics to meet stakeholder requirements rather than to focus too deeply on a particular problem faced by investment managers.  However, I think there will be some value for people interested in that particular specialty as well.

Whose needs are being serviced?

In the development of any serious analytic component the first thing we need to understand is the stakeholder community weare serving. In our case this community is tasked with managing the IT investment portfolios of large complex organizations. In order to better understand their informational requirements one of the first things I try to do is get a grasp on the informational inputs that they are currently using tomake decisions. This organizational reporting archeology work is revealing because it will often uncover vast differences in the information executives are using to make similar decisions. This is important to surface because one important benefit a BI effort can bring is more standardization to decision-making approaches and a more open evaluation of decision criteria. Another finding is that similar information is being developed for different report, for different executives by different groups.  This results in enormous wasted effort. This homework process sets the stage for the first big exercise in developing a better decision support system for our investment managers – the facilitated session.

Caption: Remember that all your stakeholders are different.
As a consultant I believe that these facilitated sessions are critical to the requirements gathering process and enable frank and open discussion of competing requirements. One of the most consistent things that I have found is that the information and analytics that are currently in use by an organization reflect a much smaller subset of the stakeholders than intended, often only the person who made the buy decision.  The second is that the stakeholders often have very different opinions on what the informational components of the analysis should be. One of the things I often do for my facilitated sessions is to create the giant wall of reporting.  Depending on the meeting space and the volume of reports that I have on hand, I will create an entire wall dedicated to the information that is currently being used to drive the decision making process. In the case of the investment portfolio management team, this will include reports related to individual investments as well as any dashboards, spreadsheets or analytics that are being used to support portfolio-wide decisions.  I will also have one of our team members develop a “core data” sheet that maps the various informational inputs being used across the current reports and analytics, along with some associated meta data regarding authoritative information sources, the process that creates the information, data refresh requirements and any obvious differences inreporting semantics. Finally, we will set up a whiteboard or flip chart board with some basic categories including columns for information that is relevant in the aggregate, information that is relevant at the discrete level, questions that we are trying to answer, and sources of data. Depending on the analysis weare trying to facilitate we may have more spaces available, but those are the basics. This set up process usually takes about two weeks depending on the size of the organization and complexity of the analysis we are trying to facilitate.  A lot of this is working through the homework processes associated with the existing decision-making and reporting artifacts.  Depending on the scope of the engagement this activity may be coming from a business process re-engineering effort or in the specific case of IT Investment Portfolio Management, we mayhave been asked in to supplement or review the process as a whole, which has implications for this process as well.
Important Factors in Understanding the IT InvestmentPortfolio
In any case, once the set up is complete and our homework is done it is time to bring in the stakeholders. I find that one of the first things that is useful is to attempt to provide some structure and scope to the exercise by focusing on the questions that need to be answered and the use cases for the analysis. One of the great benefits of this is providing a focus on the results and outcomes we are trying to achieve rather than simply organizing and reporting on the information that is available. One of the great problems I have found with BI initiatives is that they are often in large part driven by the information that is available rather than the information that would be useful to make decisions. I have never sat in a facilitated session that did not uncover some informational gap in the current decisions support scenario.  The group may discover that some of the data currently being developed and managed is not truly necessary in order to support decision-making. It iscritical that this be recorded and that the thin layer of information required to support decision making be explicit.  This way the resources that are being expended in the as-is state to support the existing decision making process can be re-allocated to meet other organizational needs. Too often reports and analysis components are added but nothing is ever removed. This is not just wasteful of resources, but it is actually harmful to the quality of the decisions that will be made. The world is a complex place for modern executives. The ability of business intelligence systems to not just provide the decision maker with relevant information but to remove informational clutter is critical to the overall quality of the decisions. Many teams are hesitant to remove analytics and reports because “somebody might be using them” or because “we spent so much time developing them.” These are not good reasons to continue maintaining these resources. This is not to say that these exercises should result in an entirely new set of reports and analytics. Maintaining legacy reporting is great as long as there is a real use case, in fact some of the best reports and analysis that will support your organization are probably sitting in spreadsheets on a few executives’ desks right now. These are usually cobbled together from several existing reporting systems by an executive’s staff and have been used to drive organizational meetings for years. Unfortunately, these spreadsheets and PowerPoint are rarely the things that survive a new BI initiative.  Instead, the reports they were cobbled together from in the old system are re-built in the new system and the need to cobble together the spreadsheet that actually drives decision making continues to need to be built every week or month.  Identifying the questions and use cases is critical because it enables the development of criteria for what stays and what goes, as well as setting boundaries around data requirements.
Developing the burning questions
Once you have come upon an initial set of questions and use cases you can begin to design analytic components to meet those requirements. In our investment manager example, one of the use cases is to identify under performing components of the investment portfolio. This enables earlier engagement by management to either increase the performance or terminate depending on a more detailed analysis. The task then becomes selecting from the larger portfolio those investments that may be at risk. In next weeks article I will provide adetailed step-by-step walkthrough of developing a meaningful analytic component for our IT Investment Manager. 

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at

If you are interested in consulting services please go to MB&A Online to learn more.

Enterprise Architecture and the Road to Enterprise Intelligence

Executives and managers are always looking for ways to increase organizational performance with regard to the effectiveness (How well am I achieving the mission?) and efficiency (Have I optimized my approach to achieving the mission?). In the course of trying to get there they have looked at many different disciplines and approaches including Enterprise Architecture. Enterprise Architecture is an alluring approach because the logic is solid; by understanding the blueprint of the organization from the context of the business architecture, data architecture, etc., you gain a deep understanding of organizational inter-relationships. This will identify the ripple effect of actions, and enable complex analysis thereby unlocking new levels of organizational performance.
Understanding Complex Relationships to Help Deliver Value
Not only should executives be able to use this body of knowledge to support a multitude of decisions, but the execution of the discipline should create a virtuous cycle whereby, better information, leads to better decision making, which leads to better processes and so on. The organization as a whole should become inherently more agile by virtue of its understanding of itself. Unfortunately, for most organizations it has been very hard to close the distance between reality and this vision of the future state. Many organizations have continued to soldier on in search of this promised to-be state because the logic behind the concept is so powerful and the return on investment, if the organization is able to achieve even a hint of the promise, is so great.
The discipline as a whole has been plagued by this reputation of over promising and under delivering almost from its inception. I think that this stems in no small part from the grand scale of the undertaking as it is often envisioned and then methodically trudged towards. Other contributing factors include the dogmatic adherence to specific methodologies and processes as well as a tendency on the part of the practitioners to over emphasize the exercise over the end state. I think this last part, the end state is the where the real disconnect occurs. The problem is that for executives and the managers, the desired end state is a higher performing organization because of the impact of getting the right information, at the right time, to make the right decision.  Unfortunately, the desired end state of the architecture program to often appears to be a complete architecture, adherence to architectural process, the evolution of architectural process and/or the perfection of the PowerPoint presentation. I have no doubt that there is real virtue in the application of many of those concepts and capabilities in order to achieve real and lasting value from your Enterprise Architecture, however I think that it is important to first start by ensuring that your organization is approaching Enterprise Architecture as a means to achieve Enterprise Intelligence.
What is Enterprise Intelligence? Enterprise Intelligence is the decision making capability that enterprise architecture should be leading you to deliver to your stakeholders. Executives, managers and other stakeholders should be able to intelligently query an organizational service that can provide answers to questions that lead to greater efficiency and effectiveness like:

  • Are we efficiently purchasing software/hardware in order to deliver organizational capabilities?
  • How are the services we provide externally and internally performing?
  • How does information flow within the organization?
  • How are the services that we provide supported with regard to resources (IT/HR/Physical Assets)?
Develop Resources that Enable Stakeholders to Improve Performance
Most importantly the questions and answers need to resonate with your organization. It is critical that the outcomes of the processes and activities you perform be things that your stakeholders will use. One of the great failures of many Enterprise Architecture efforts is the failure to make this connection to service provision. It is absolutely critical that your end users be engaged and that your products are used in the decision making process. Otherwise, someone will inevitably come around to question why the effort is being undertaken at all. Nothing, I’ve said above should come as a surprise to anyone who has been engaged in these efforts for any length of time. The temptation to refine the HOW of the EA program is simply too great, and an entire industry of software products, methodologies and consulting services have grown up around it. However ignoring the WHY, is in my opinion, the single greatest cause of the failure of EA to live up to its promise. EA programs need to be run as a service organization to succeed and a major part of that is focusing on the customer experience. The EA team must be in the business of providing UNIQUE insight into the organization, and they must show that they value and are responsive to their customers. That is in large part to say that the value EA provides should be in linking together information in disparate systems within the organization. Tying it to some context provided by the EA organization and making that combined information available to executives and managers in a way that facilitates decision making, prompts further investigation and provides feedback on performance.

Getting from Information to Outcomes Requires Unique Insight
How do you do that? I think understanding the process required to deliver on that promise within a particular organization can only be done by starting from the stakeholders and working backwards in the process for deriving it. I am not saying their is no place for best practice and methodology, but I think an organization is better suited to make a determination on methodology by starting from an evaluation of the decisions it does make (and should make) first. Do not forget the “should” in the last sentence, one of the things that EA as a discipline has gotten better at is in providing examples of reports and artifacts that can be used to support different aspects of the architecture. Some of these are quite useful and one of the real benefits of the extensive promulgation of best practice and methodology-related documentation within the discipline has been the ever increasing number of example reports, dashboards, models and analytic artifacts that are available online. Looking at what others have developed as an end state should help you and your stakeholders identify things that you could use for your own purposes. This is also an area where looking at the various tools on the market can be of assistance as well. Tool vendors often have some unique insight and experience by virtue of working with many programs in a relatively compressed time period, however it should be noted that this can also be a limitation because their job success in large part is predicated on how well they are able to get the software in the door; not on the long term success of the program.  Obviously, real success for these companies comes when their clients succeed, so they will be motivated to position your team to succeed, especially in the run up to the sale.
Without diverting this discussion into an extensive look at EA tooling, I think one of the things that must be recognized is that tooling choices are important because of the way in which they can accelerate the path to value for a program. This will enable the mangement of this complex organizational decision support tool, and enable the type of ongoing analysis and reporting that drives the customer’s experience of EA products. If your tooling is only available to a select stakeholder community you will need to ensure that the value of your teams work makes it into the hands of your customers (executives, managers, etc). If the tooling interface is too complex or if the tool cannot be configured to sustain high data quality, again your stakeholders will suffer.
The tooling should also enable your program to combat another EA program killer, which is stale data. A real Enterprise Intelligence capability requires that the data being analyzed be correct. The user (customer) community will need only find stale data a few times before deciding to get information from other sources. For the architects developing this informational service, it is critical to understand where information comes from, the process that creates it (manual, automated, etc), the refresh requirement in order to maintain accuracy, and the precision/accuracy of the data. This enables the team to provide stakeholders an explicit understanding of the level of confidence they should have in the information they are using to make decisions. One of the issues I often see in the use of EA information to support decision making is the hesitancy of stakeholder to use data to underpin important decisions because the EA team has failed to provide a mechanism for the user community to gain confidence in the information. One thing that programs should do in order to ensure customer trust is to make sure that they have made it easy for stakeholders to develop confidence by providing clear labels, open discussion of informational flows and appropriate messaging during training sessions and service desk calls.

Establish a Clear Line of Site from Inputs to Reporting
Additionally, achieving the benefits of Enterprise Intelligence requires a real focus on strategic communications, training and support. Far too often the focus of an EA effort is on process and content, and while I agree that without these your EA program will certainly fail, these alone are not enough to sustain a program. The stakeholder community cannot leverage any of your good work without an understanding of what information is available, how to access it and an understanding of who to call in order to ensure they get value from it. The point has been made often with regard to the corporate use of big data, analytics, and statistical information that these capabilities often under deliver on their promised return of investment because of a lack of organizational readiness to leverage them. The same is true for Enterprise Architecture. A commitment must be made on behalf of the program to not just develop the information and processes needed to succeed, but to mentor those that are supposed to be receiving value from them and how to get that value. A successful EA program invariably includes someone that is focused on strategic communications and marketing in order to ensure that the organization is aware of the value available from the program. This messaging is further developed and enhanced by ensuring that training is available across the stakeholder spectrum. Too often these types of programs inappropriately skew towards a “Let me tell you about how to do EA” approach. This is not productive for those whose job it is to use EA products to get organizational value. I recommend that one starts the process by understanding the stakeholder community and their individual use cases for EA. Then develop a training curriculum that specifically helps them  get the results they need from EA. Another approach is to stack training in order to meet specific organizational transformation objectives. For example, the success of a particular program may be enhanced by ensuring that training is available to help architects understand how to better use a specific tool that will be used to meet an objective, this may be followed by a workshop to meld training with organization specific content to drive a specific outcome while building skills. This may also be combined with executive brown bags that ensure that the people who need to use the information that is being developed are ready to leverage it for the greater good of the organization when it becomes available. In this way, great training programs not only increase the ability of the organization to achieve performance targets, but they also serve as another outlet for strategic communications.
Remember that Different Stakeholders Need Different Training
Finally, great EA programs make sure they deliver a top notch service experience for their customers including making sure someone is there to pick up the phone and support the user community. When you think about the dollars that have been invested to get the right information, in the hands of the right people, so they can make the right decision it is critical that the program is there to support its customers in getting the best value. So often I find that executives and mangers have essentially opted out of their EA programs because “It’s too hard to get real information” or because “I don’t know where to start.” Even after you have done the training, held your “Lunch and Learns” and provided workshops you still need to be there when your customer needs help. Every support or service request is a critical opportunity for the EA program to shine. I highly recommend that a  single e-mail address for support be used, and have a single phone number for people to call. It goes without saying that this service needs to be RESPONSIVE.  Being a part of a business or mission success is the start of an ongoing relationship that will sustain the EA organization in lean times and ensure that there are vocal champions outside the EA organization. That’s it. This is all you need to succeed in turning your Enterprise Architecture program into an Enterprise Intelligence program, and winning the hearts and minds of your customers.

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at

If you are interested in consulting services please go to MB&A Online to learn more.

3 Keys for New Managers

Most people’s introduction to “formal” leadership is as a newly minted manager. One of the first things newly appointed managers and “leaders” learn about their new position is that they no longer have time to do any “real” work. As I’ve talked to people and learned from hard experience, leading and managing is hard work. Those who cannot come to grips with a system for dealing with the pressures of doing while managing the doing of others will rapidly find that their work life is becoming less and less fulfilling and their calendar more and more full. In talking with lots of managers over the years as a consultant and as the manager of my own staff I know first hand how challenging it can be to lead and execute at the same time. One of the first discoveries that most managers make is that the time they use to have to execute their own tasking has now shrunk dramatically. For people who are used to consistently working harder, to perform better, to deliver more this can present a signifigant hurdle to overcome. As a new manager the temptation is to keep the velocity and effort you put towards your own work constant and simply add your additional duties as manager to what is now a longer list. This is simply not a sustainable path. I’ve watched people ruin their health, their home lives and often their relationships with their co-workers and staff because they simply could not re-balance in their new role. I won’t say that the following will make managing easy, but hopefully it will provide a perspective that enables you to shift your approach. The key is to take full advantage of your team which enables you to look at a slightly bigger picture, and shift your focus just a bit farther out into the future.

1. Change your expectations about your work and re-define success.
The first thing I think most managers need to do is adjust their expectations with regard to the quality with which they execute some of their tasking. As a subject matter expert or line worker you may have had the luxury of consistently delivering everything you touched to the highest possible standard. In fact you were probably encouraged to do so because that constant focus on quality is what the organization was striving for and may have played an integral role in getting you to the leading role you occupy today. This may sound strange, but you are probably going to have to unlearn some of those great habits and begin to really think about the level of effort required to get a product together that will meet the requirement, not exceed it. If you are thinking that I just arbitrarily lowered organizational standards you aren’t reading the last paragraph correctly. I am advocating that managers need to know what the final objective is well enough to identify the correct level of effort and polish required to execute on the mission. As a line worker, subject matter expert of whatever your previous role on the team this was probably not part of your job description. Quality standards are set and achieved or exceeded by the folks who work for the managers. Now as a manager you need to fight to ensure that you do not set artificially high standards for the wrong tasks. Having well written reports is great, but there is probably a balance to be found between copy editing and meeting the mission. I believe in good grammer, but I also believe that their is an appropriate level of effort to be expended on every task and part of the managers job is to know where that line is and make sure they cross it every time, just not by too much.

Be careful not to unnecessarily overshoot your target.

2. Think system first, tasks last.
This is closely tied to the last point about being able to back down your personal quality meter where appropriate. Where you may previously have been responsible for the flawless execution of a part of the unified whole you are now responsible for a more complex delivery. This requires a mind shift in almost everything you do. One of the first things I try to determine every day as I ride into work is identify who I need to talk to this morning so that they can be as productive as possible all day. Their is an enormous temptation as a manager to do your own tasking first, or to close the door and just make it through one thing first before you talk to your staff. This approach will kill you over time. Think of the big picture and get your staff working towards the big picture first. I have found that invariably my own tasking is altered by what eventually comes out of the conversation with staff regarding direction. More importantly if I sit down and work on my issues first I have just left the entire team working towards an objective that is not clear or worse no longer valid. You will lose the good will of your staff if you let them row in the wrong direction to often or for too long. I know that I ask a lot from the people I work with so I try to make sure that I don’t ever waste their time. I also encourage them to ask questions and get clarification so that they don’t waste the company’s resources moving in the wrong direction. This should not be confused with riding over top of people and micromanaging which is covered in the next section.

Make sure you look at the big picture.

3. Relax, let other people work and learn.
The hardest thing to come to grips with for me personally as a manager was the realization that my way wasn’t the only way to get something done. There is an enormous temptation to intervene while your team is in process and have them do things your way. After all, you are now the boss – shouldn’t your staff do things your way? I have no issue with a manager interceding in order to ensure the success of the mission. I also have no problem with a manager providing mentoring, feedback, or instruction to staff on how to perform tasks or meet organizational goals. However, I think that managers benefit greatly from allowing staff to develop there own approaches and succeed or fail on their own merits whenever possible . This builds the managers trust and enables the manager to focus on other things that may require attention while at the same time enabling staff to develop confidence and independence. These are critical to the larger team succeeding. The world is a competitive place and the highest performing teams are those that can successfully execute with a minimal instruction set, enabling the manager to focus on looking a little farther forward in order to smooth the way forward. This last part is critical, managers that become so deeply engaged in the near term objective that they can’t see the big picture set their team up for failure. The managers primary role shouldn’t be as a another set of hands on a task, or as the person in charge of counting the beans, or even as the person in charge of making sure things get completed. The manager can do all of those things, but none of those are as important as setting the course forward, ensuring the team has the requisite skills and character to achieve the mission, and understanding and communicating the big picture.

Learn to depend and trust your team. 

These three keys to managing to succeed are great things to think about as you come to grips with managing your staff and trying to manage your time and resources in order to help your team succeed. I think one final thing to keep in your mind at all times and particularly as you work through difficult managerial problems is to put yourself in the shoes of your team. How would you have reacted to your approach? I have changed course on many, many decisions because they were only a  great idea from my perspective. It usually isn’t that hard to put yourself in someone else’s shoes, a little imagination and couple of minutes are all it takes. The problem is remembering to do it, particularly as you spend more time in the managerial role and become more accustomed to people following your direction. Make this simple activity a habit and use it before you set direction for staff, give a briefing, or intercede in a project. The ability to put yourself in the shoes of another is a skill you should nurture not just in order to improve your interaction with your staff but because it is critical throughout your business life. Negotiations, working with customers, even your interaction with your own management will be improved by working on seeing things from the standpoint of the other stakeholders that are effected by the action.

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at

If you are interested in consulting services please go to MB&A Online to learn more.

FedBlueprint: Informational Domains and Reporting for Federal EAs

When enterprise architects examine the information required to plan, organize, lead, and manage their EA, the information set is a bit different from that required by the private sector. These questions are just a bit different than those that would engage a private sector organization’s leadership, partly because of the unique nature of the business of the federal government. Of course, part of it can be directly tied to specific regulations that require certain information be available to external stakeholders (Congress). By and large however, federal EAs are interested and confronted by the same issues as their private sector counterparts. The same pressures surrounding doing more with less budget, transformational technology and trends (cloud, social, big data), evolving compliance requirements, and operational environments are changing the lives of executives, regardless of their affiliation with private or public sector. One way that I like to look at this core set of information is to break it into six major components or domains as follows:

  • Performance Domain: is about understanding how the organization measures performance. This area does not hold the actual assessments against key performance indicators, but rather is focused on what is being measured and how it is being measured. This domain should enable executives to understand the performance management system that is in place for the organization and enable them to see linkages across all of the component parts that enable enterprise performance. Helps answer these questions:
    • How are we measuring performance across the enterprise?
    • How do my investments align to the performance management strategy (e.g. PRM)?
    • What is being measured via Key Performance Indicators across my organization?
  • Business Domain: includes the information related to the business processes, investments, and organizational structure of the organization. A review of the business domain should enable an executive to understand informal and formal organizational structures, the business processes leveraged by those organizations, and the investments of the organization. Helps answer these questions:
    • How are my investments performing in terms of cost and schedule?
    • What is the likelihood and impact of various risks to the projects in my organization?
    • How do my investments align to strategy?
    • Are my investments being managed properly?
  • Information Domain: includes an understanding of the critical information leveraged by the organization. This domain should enable executives to understand the strategic role of data within the organization.  It should also identify areas of opportunity based on a helping identify the relationship between key business concepts, processes and applications working together in the integrated enterprise. Helps answer these questions:
    • How is the data we’re collecting being categorized?
    • Are my applications implementing proper data exchange models?
    • What data is being exchanged between applications?  
    • What data should be exchanged?
  • Applications & Services Domain: enables executives to understand how technologies and resources are combined to create applications and provide services. This domain provides insight into the combinations of things that create business and organizational value. Helps answer these questions:
    • Are my applications in the appropriate infrastructure?  
    • Do I have all of my major applications in an appropriate location?
    • What applications are running on non-standard technologies?
    • Are there similar applications in the enterprise that I can leverage to generate cost-savings?

  • Assets, Technology & Infrastructure: enables the organization to understand the the critical infrastructure, technology and resources required to provide value. These run the gamut of enterprise value from datacenters and radio towers, to manufacturing plants and forklifts. The granularity of the information required by executives from this domain will vary widely. Helps answer these questions:
    • What will be the impact of migrating technology to different stages of its lifecycle?
    • Do we have an appropriate level of data center  consolidation?
    • How is technology distributed throughout the organization?
  • Security & Risk: enables executives to understand the juxtaposition of risk and security as it pertains to the delivery of value and the ongoing operation of the organization. This area should enable executives to understand how physically secure their assets are in the bricks and mortar world, as well as how secure the informational aspects that support the organization’s value chain are supported as well. Helps answer these questions:
    • How well are we protected against known security threats?
    • How informed is my organization about security best practices?
    • How many security incidents have occurred in the last 30 days?

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at

If you are interested in consulting services please go to MB&A Online to learn more.

3 ways to go from Compliance to Transformation

I think that organizational compliance efforts represent one of the biggest untapped opportunities to increase organizational performance and/or leverage these required activities in the service of organizational transformation. In both the public and private sector, compliance is often spoken of derisively as something to be done only to the degree that is required to check the box and as an impediment to achieving the performance goals of  the organization. Things like Sarbanes–Oxley in the private sector and Clinger-Cohen in the public sector are viewed as an organizational tax with limited benefits, most of them are for external stakeholders and few pertain to (OUR) organization. This small minded view is wrong minded for three reasons.  First and foremost it sets a poor tone for the compliance effort as a whole. Whether you agree or disagree with the objectives, implementation, or impact of the legislation, the fact is that not complying will have negative consequences for your organization that run far beyond the costs associated with compliance. Secondly, most of these mandates were developed by smart people with good intentions who may have a broader view of performance than simply your organization. Finally, a well run organization should be able to handle most of these initiatives on the basis of being well architected. If you aren’t able to easily identify and prove controls within your financial system as required by law, then perhaps deeper problems exist within your organization than the costs associated with compliance. Compliance initiatives simply should not present enormous difficulties to the well run organization. Here are three keys to getting your response to compliance initiatives right:

  1. Take a step back and look at the big picture. One of the biggest drivers of cost with regard to compliance initiatives is that they are often handled separately from the execution of normal planning and reporting activities, even where the information required is significantly similar to other information requirements. Part of reducing the cost of compliance is in ensuring that the requirement is put into the proper organizational context and making sure, to the best of your ability, that the requirement is fitted into a appropriate organizational context.
  2. Avoid the Compliance Silo
  3. Find the right organizational owner. Once you have an understanding of where the compliance activity fits in the big picture of the organization, it is time to find a home for the requirement within the organization. This is a critical success factor because choosing the right organizational home will have an enormous impact on the overall cost profile of meeting the requirement, as well as determine how much re-use of any informational requirements occurs. Drivers for organizational ownership include ability to meet the requirement, familiarity with the data required, ability to provide appropriate executive buy-in, and capabilities required for execution.
  4. Get the Req to the Right Person
  5. Figure out if any of the data can help drive performance. This is critical to lowering the actual cost of compliance to the organization. If the organization is able to lower the cost to be compliant and therefore increase its relative performance to the competition, it will drive performance. If the organization is able to leverage the compliance requirement to better understand their organization or facilitate transformation objectives, it will drive performance. The same business process models that show how an organization ensures internal controls can be used as a mechanism to drive organizational performance.
Find Opportunities to Drive Performance

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at

If you are interested in consulting services please go to MB&A Online to learn more.