|
|
The Enterprise: Mystery Unraveled
By James E. Seymour, Jr.
Copyright 2010 by James E. Seymour, Jr.
All Rights Reserved. Copyright registration number: TXU 1-741-597
Smashwords Edition
ISBN-10: 0-692-01317-2
ISBN-13: 9780692013175
About the Author
James Seymour is a graduate of the University of North Carolina at Chapel Hill with a BA in history and political science and the University of Kentucky with a MA in history. He became first involved with computer technology in 1965 with the mainframe environment at North Carolina.
While in the United States Army during the Vietnam War, he was on the small team which worked with the mainframe setup at the Pentagon for various military strategic scenarios.
Since 1972, he has been involved on many, varied computer environments with the second point-of-sale and inventory control project in the retail industry, analytical programs and database initiatives in the insurance and benefits industries, loss control start-ups, and many other inventory control and sales tracking projects throughout many different industries.
From 1987 through 1995, Mr. Seymour was an instructor of database management in the community college system of the state of Kentucky. In this capacity, he created the first database management and C programming courses in the state of Kentucky and helped both public and private entities with urgent training needs including the programming of guidance systems on cruise missiles for Desert Storm.
Before 1985, he was a system administrator, network administrator, programmer, and database administrator. Since 1985, Mr. Seymour has been a senior enterprise architect, senior data architect, and senior database administrator working primarily with DB2 and Oracle DBMSs on multiple platforms plus SQL Server beginning with version 7.0. During this time, he has successfully developed and managed several major business and information technology projects for a Fortune 100 corporation in the United States, Canada, and Great Britain.
Mr. Seymour is currently the CEO plus Senior Business and IT Consultant for Sneezing Dragon Business & IT Consultants, Inc. This firm helps small, medium-sized, and large businesses with solutions to various problem areas. It operates both in the United States and in many other countries around the world.
Mr. Seymour can be reached through the email address of sndragn@gmail.com.
Dedication
No book is created without the help of more than just the author. This has been the case also with this book.
First of all, I want to thank my wife, Evelyn, who has supported me and motivated me even on the bad days to pursue, write, and publish this book. She is the ultimate life’s love and partner.
I also want to thank various persons who have worked with me over the years in both business and information technology fighting the good fight to clean-up businesses and data, help both clients and employees, plus start and grow honest and knowledgeable companies.
Enjoy the book.
James E. Seymour, Jr.
December 8, 2010
Preface
Any project can be a worrisome task; but with the economic hardships, tight budgets, reduced “brain trusts”, and sometimes poorer senior management, projects can be like solving a complex mystery. There is the finding out who are the true stakeholder/stakeholders, finding the correct information that can define the project, the gathering of the project team, the creation of the project budget, the planning of the project details, and more and more and more.
A project involving both business and information technology need not be mysterious, worrisome, nor daunting. The ultimate trick is organization, experience, documentation, and leadership from the start. Additionally, add active support from the senior executives of the organization, actual authority for the project leader, plus avid dedication to the project by all participants.
Even the enterprise project – often the most daunting of all projects – need not be a devilish task. Organize the task into components – which we will discover in this book. This organization plus documentation and wise leadership can make even the enterprise project doable and within most budgets.
But why even tackle such a task? Well, is your data fully clear and correct or do you find that support, marketing, and billing departments are finding that the data is often embarrassingly incorrect? Additionally, there are more and more regulations and possibly even laws which demand the documented processes of keeping data both clean, accurate, and private. The alternative experience for the organization can be a federal-level audit and penalties plus a public relations nightmare.
You tackle such projects because bad data leads to unhappy clients, which leads to unhappy employees and reduced revenues. Moreover, if you want to be able to analyze your business data in order to make effective, accurate executive decision, you had better be moving to an enterprise project as presented in this book, or you will be out of business.
It is just that simple.
James E. Seymour, Jr.
December 8, 2010
Chapter 1: Concepts & Terms
Before anyone can do legitimate and successful work on any project, that person must understand the terms frequently used within the project. An enterprise project is filled with terms that must be thoroughly understood.
In this chapter, we will be exploring the concepts of enterprise, enterprise project management, and strategic enterprise management. In later chapters, these and other definitions will be applied to specific steps in the overall process. This approach will not bury you in a vast amount of terms and definitions until you actually need them.
The Enterprise
First of all, there is the term, “enterprise”. Although there is a television and movie spaceship called the Enterprise, this is not what we are talking about here. In the Webster’s Collegiate Dictionary, enterprise is defined as an undertaking , especially one which involves activity, courage, energy or the like; and important or daring project; a venture. This definition is close to any enterprise project because the project will require activity, courage, and energy – large amounts of all of them.
An interesting point about attempting to find a definition for “enterprise project” is that there is nothing at this time. Here is an attempt at a functional definition. An enterprise project is a project which deals with all pertinent aspects of the business beginning with defining each elemental application, network, hardware system, operating system, database system, every business policy and procedure, and business requirement within each division of the whole parent business – whether private or public in nature. Next, there must be a thorough design and documentation of how each element within each division interfaces. Finally, there must be an equally thorough design and documentation of how each divisional enterprise interrelates with every other divisional enterprise within the overall corporate operation.
Now that we have defined enterprise and enterprise project, let us investigate enterprise project management (EPM), the strategic enterprise project, and enterprise architecture.
Enterprise Project Management
Though enterprise project management has been a business and technology issue for a long, long time, formalization of the terms and processes are a rather new effort. Why you might ask? There was not the emphasis on the many aspects of compliance for both business and technology that there is now. If a firm is audited by federal or state agencies, such an audit can be enforced by a large collection of laws and regulations – Sarbanes-Oxley, GILBA, etc. The provisions of these laws and regulations include required knowledge of the components of the firm’s enterprise which must be documented.
Enterprise Project Management (EPM), in broad terms, is the field of organizational development that supports organizations in managing integrally and adapting themselves to the changes of a transformation.
Handling multiple projects requires more than just a “gut feeling”, some project experience and a basic understanding of baselines and resource utilization are definitely required. EPM also requires a thorough understanding of multiple project interfaces, global templates, web-based project interface among team-members, information sharing and security, and finally, portfolio management. The bottom line is that EPM delivers tools and technology to project managers that will truly increase their throughput. EPM allows for better time management, resource management and better accountability. Through the use of sophisticated views and dashboards depicting Key Performance Indicators (KPIs), executives can quickly make key decisions on resource commitments.
Enterprise Project Management (EPM) is for every project manager, resource manager, executive and PMO office involved in handling and governing complex and multiple projects with respect to a well defined performance matrix. Properly used, EPM helps to ensure project improvements by providing timely data in a format that eliminates clutter and noise for executives and project managers. With EPM, you can expect to:
Better utilize resources by defining resources with multiple attributes
Focus on key projects by assigning priorities based on Key Performance Indicators
Create an OLAP cube and perform a sensitivity analysis on multiple project attributes
Provide reports that accurately reflect inter-project and intra-project complexities
Enterprise Project Management also enables an organization to create a variety of custom templates for various activities. For example, SixSigma projects can be incorporated by using a DMAIC template. EPM also allows an organization to leverage resources in ways not possible by using stand-alone project management systems such as Microsoft Project and Primavera.
As already mentioned, in recent years, with general adoption of information technology (IT) governance practices, Enterprise Project Management has become more specific. Whereas in the 1990s focus was generally on the management of the single project, in the subsequent years the focus lay more on the fact that a project is likely to not be the only one in the enterprise. The project co-exists with many other projects in the enterprise, or may be part of one or more programs. It may utilize resources (human and non-human) that are shared among other projects.
When working on a project in a single division, missing the interwoven nature of projects in an enterprise can cause problems on one or more other projects ongoing in the enterprise. Resources can quickly become over-used and even crash – people too. Clients’ service either noticeably suffers, or worse, fails entirely. Ignorance is not an excuse when clients start leaving.
In order to facilitate governance and manage a business correctly, it has become essential to be able to manage, monitor, and assess the status of all projects (and other assets too) in the enterprise, through a set of uniform Enterprise Project Management processes, methods and application packages.
EPM is today’s answer to handling multiple projects efficiently and is a necessary tool for any company involved in handling complex projects involving significant resources.
The Project Management Office
The Project Management Office (PMO) in a business or professional enterprise is the department or group that defines and maintains the standards of process, generally related to project management, within the organization. The PMO strives to standardize and introduce economies of repetition in the execution of projects. The PMO is the source of documentation, guidance, and metrics on the practice of project management and execution. Obviously, the persons composing an effective PMO group must be professionals who are dedicated to proper knowledge, experience, planning, documentation, design, and implementation.
A good PMO will base project management principles on accepted, industry standard methodologies such as PMBOK or PRINCE2. Increasingly influential industry certification programs such as ISO9000 and the Malcolm Baldrige National Quality Award (MBNQA) as well as government regulatory requirements such as Sarbanes-Oxley have propelled organizations to standardize processes. Organizations around the globe are defining, borrowing and collecting best practices in process and project management and are increasingly assigning the PMO to exert overall influence and evolution of thought to continual organizational improvement.
If you have not developed a set of best practices for the PMO as well as the Enterprise Project and Enterprise Project Management, start at once. Have an informed person within the corporate enterprise read each document plus sign-off and date a form verifying that a specific person has read the best practices document. This includes the CEO, COO, CFO, CIO, and VPs as well as the business and IT personnel.
According to the Standish Group Chaos Report, 1995, 90% of projects do not meet time, cost, and/or quality targets. Only 9% of large, 16% of medium and 28% of small company projects were completed on time, within budget and delivered measurable business and stakeholder benefits. There are many reasons for such failures. As per a KPMG survey of 252 organizations, technology is not the most critical factor. Inadequate project management implementation constitutes 32% of project failures, lack of communication constitutes 20%, and unfamiliarity with scope and complexity constitutes 17%. Accordingly 69% of project failures are due to lack and/or improper implementation of project management methodologies. In other words, procrastination, stupidity and incompetence cause the failure.
Establishing a PMO group is not a short term strategy to lower costs. Surveys with companies indicate that the longer they have an operating PMO group the better are the results achieved to accomplish project goals (which might lead to lowering costs).
PMOs may take other functions beyond standards and methodology, and they may also participate in Strategic Project Management (see in its section below in this chapter) either as a facilitator or actively as an owner of the Portfolio Management process. Tasks may include monitoring and reporting on active projects plus reporting progress to top management for strategic decisions on what projects to continue or cancel.
A PMO can be one of three types from an organizational exposure perspective: enterprise PMO, organizational (departmental) PMO, or special–purpose PMO. The Project Management Institute (PMI) Program Management Office Significant Interest Working Group (PMOSIG), views the PMO as a strategic driver for organizational excellence and seeks to enhance the practices of execution management, organizational governance, and strategic change leadership. As the largest community devoted to the PMO, with over 4,000 members globally, the PMOSIG is the central forum to collaborate, expand the knowledge base, and mature the PMO practice within their own organizations and the business community at large.
The EPM & the PMO Together
Typically, organizations that adopt an Enterprise Project Management (EPM) methodology might set up a Project Management Office (PMO)/Enterprise Project Management Office (EPMO), which is said to be more successful than a traditional PMO in addressing the priorities of the organization as its scope is enterprise-wide. This approach might select and adopt a Project Management Methodology like PRINCE, PRINCE2, PMBOK, a more proprietary method, or go with the concepts of the IPMA Competence Baseline as a foundation for development and certification of project managers and their knowledge, experience and behavior. They might even select and implement a software system to support Enterprise Project Management.
An even more recent evolution in Enterprise Project Management is not only to plan and track the existing set of projects, but to create a portfolio as EPM (per budget size, per calendar year, per budget year, per business line, etc.) of existing and future (demand) projects. Just as with a portfolio of shares, Project Portfolio Management is the activity of selecting which projects to keep in portfolio (because of their anticipated value) and which ones to discard (because of their obsolescence or their lack of thoroughness). Project Portfolio Management includes the creation of various scenarios to decide which is the most optimal portfolio (for a certain year, business, budget, or other factor). Once the contents of the portfolio are agreed upon, it is critical to constantly scrutinize how the individual projects are evolving in terms of quality, cost and schedule.
From an IT management perspective, Enterprise Management essentially means enterprise-wide network administration, which is becoming increasingly complex. The corporate network environment is no longer tied to a single vendor, let alone a single platform. More and more, corporate intranets are multi-domain, multi-protocol, multi-platform systems. They contain hardware and operating systems from a number of different, competing vendors. This situation creates administrative overhead that can easily make the cost of owning such networks prohibitive for all but the largest and most profitable organizations.
Implementing an EPM toolset needs to be considered in light of the organization’s project management maturity and the methodologies, processes, and governance structures that are currently in place. There are many organizations that can support such implementations. Tools that support EPM must include collaborative enterprise project management software such as allWISER, Wrike, Deltek EPM Suite, and Microsoft Project Server.
Role of Project Portfolio Management
Project Portfolio Management is a term used earlier in this chapter; but it was not logical to include a definition at that time. It is now. Project Portfolio Management (PPM) is used by project managers and project management organizations to describe methods for analyzing and collectively managing a group of current or proposed projects based on numerous key characteristics. The fundamental objective of the PPM process is to determine the optimal mix and sequencing of proposed projects to best achieve the organization’s overall goals – typically expressed in terms of hard economic measures, business strategy goals, or technical strategy goals – while honoring constraints imposed by management or external real-world factors. Typical attributes of projects being analyzed in a PPM process include each project’s total expected cost, consumption of scarce resources (human or otherwise), expected timeline and schedule of investment, expected nature, magnitude and timing of benefits to be realized, and relationship or inter-dependencies with other projects in the portfolio.
The key challenge to implementing an effective PPM process is typically securing the mandate to do so. Many organizations are culturally inured to an informal method of making project investment decisions, which can be compared to political processes observable in the United States Congress. However, this approach for making project investment decisions has led many organizations to unsatisfactory results and created demand for a more methodical and transparent decision-making process. That demand has in turn created a commercial marketplace for tools and systems which facilitate such a process.
Some commercial vendors of PPM software emphasize their products’ ability to treat projects as part of an overall investment portfolio. PPM advocates see it as a shift away from ad hoc approaches to project investment decision-making. Most PPM tools and methods attempt to establish a set of values, techniques, and technologies that enable visibility, standardization, measurement, and process improvement. These tools attempt to enable organizations to manage the continuous flow of projects from concept to completion.
Treating a set of projects as a portfolio would be, in most cases, an improvement on the typical, unfortunate analysis of individual project proposals. The relationship between PPM techniques and existing investment analysis methods is a matter of debate. While many are represented as “rigorous” and “quantitative”, few PPM tools attempt to incorporate established financial portfolio optimization methods like modern portfolio theory or Applied Information Economics, which have been applied to project portfolios, including even non-financial issues.
EPM is today’s answer to handling multiple projects efficiently and is a necessary tool for any company involved in handling complex projects involving significant resources. Using the key features of EPM as it relates to Microsoft’s Project Server offering, you can:
Monitor progress and make informed decisions – A central repository of project portfolio and resource information can evaluate and model schedule, resource, and cost data over time and across projects.
Customize and exchange data with other programs – Uses open architecture (featuring XML messaging and SOAP) and extensive API connectors to exchange information with other business programs and databases.
Scalable to meet changing business needs – Scalable design allows database load to be distributed across separate database servers.
Increase participation and maintain up-to-date data – Microsoft Office Outlook® integration lets team members submit project task progress in their Outlook calendars for greater participation in projects.
Enable information sharing and collaboration – Improves coordination across teams through Project Web Access. Centrally stores, links, and shares related project details such as documents, issues, and risks.
Strategic Enterprise Management
Strategic Enterprise Management (SEM) is the management techniques, metrics, and related tools that companies can use to make strategic decisions. In practice, it is an advertising term intended to lend credibility to an information technology system.
Many project management offices (PMOs) are not often successful in addressing the strategic priorities of their organization because they are departmentally based and not enterprise-wide. This reduces their span of influence and limits corporate support. Research shows that PMO’s are more effective and can better impact the bottom line, when they are operating at the corporate enterprise-wide strategic level, rather than at the departmental level.
According to a study, fifty-seven percent (57%) of survey respondents indicated that all levels within an organization had not embraced the direction of the PMO. However, sixty (60%) of interviewees who headed departmentally based PMOs indicated that all levels of their departments embraced the direction of the PMO. The findings suggest that departmentally based Project Management Offices are successful in their own silos; but they are not accepted outside their span of influence, and therefore, are unable to influence the organization as a whole. [Data is from a comprehensive research study of 750 global organizations that was conducted by Business Improvement Architects and reported by the PMTI Institute in its Enterprise Project Management. No date. PMTI Institute. http://www.4pmti.com/enterpriseprojectmanagement.aspx.]
An examination of the traditional Project Management Office model compared to the more current corporate-wide (enterprise) approach helps in building the case for moving the PMO to this more strategic, enterprise-wide position.
The Traditional Project Management Office
Although a discussion on Project Management Offices was presented earlier in this chapter, some points need to be discussed again here.
Project Management Offices are located only within a department in their organizations. Generally these project management offices are only assigned to the IT or Engineering department. They struggle to maintain a strategic orientation because they are not set-up to affect the entire organization – there are “turf wars” that rapidly develop between the different divisions. This is because many project management offices started off from a grass roots approach. They were started by an individual or small group of individuals who saw the need to bring more control over the management of a portfolio of projects, which, although based on good intentions, lacked senior management’s approval with possible direction and control. This senior management lack of support and authorization is a major problem for project management offices even within their own divisions.
According to the research, initial effort on the part of the PMO usually included presentations to increase departmental awareness and provision of training for the management team to help ensure their understanding. This helped the PMO to move from a grass-roots approach into a more formal structure. Generally, these Project Management Offices gained success through their department.
Their success increased when they were able to get executive sponsorship for their efforts, but this was not always the case. Executive sponsorship very often does not translate into true support. In fact, the research shows that executive sponsorship was a critical requirement for PMO success, and the lack of it was a key reason for failure of the PMO.
The Enterprise Project Management Office
The next evolution of the Project Management Office is for it to move into the corporate side of the business without the petty politics often found on that level. Ideally, the creation of the traditional PMO into a true Enterprise PMO allows that PMO to gain a strategic position within the organization and works to ensure that projects proceed on the basis of their strategic alignment to the objectives of the organization. A PMO that is organizationally based versus departmentally based is more likely to get executive support. After all, project management should not be a departmental strategy; it should be a larger organizational strategy.
The senior management team must show a strong commitment to the Enterprise PMO by requiring all project teams to adopt the process, tools, and templates of the Enterprise PMO. The Enterprise PMO should ensure projects are aligned with corporate strategy and direction. Senior executives should be most concerned with how an Enterprise PMO will positively impact the organization as a whole, each individual department, and their customers.
In some organizations, the Enterprise PMO will oversee the management of all strategically aligned projects. In larger organizations, the Enterprise PMO will have departmentally-based PMOs reporting directly to them. This provides them with an opportunity to align all corporate-based and departmentally based projects against the strategic plan and to manage project prioritization and resourcing issues. This is an example of what the Enterprise PMO structure looks like:
Figure 1-1: Enterprise PMO Structure
[Chart taken from Stanleigh, Michael. The Strategic Importance of the Enterprise Project Management Office. January 9, 2010. The Project Management Hut. http://www.pmhut.com/the-strategic-importance-of-the-enterprise-project-management-office.]
Measuring the Impact of the Enterprise PMO
The Enterprise PMO is more likely to receive continuous support from the management team if they can provide both quantifiable and qualitative data on projects that they are responsible for overseeing on a weekly or monthly basis. This data can include a comparison of the number of projects as well as the changes that have occurred since the implementation of the Enterprise PMO. It includes the number of projects that:
Were completed within their time constraints since the implementation of the Enterprise PMO as compared to the number of projects completed within their time constraints prior to the implementation of an Enterprise PMO.
Were completed within their budget constraints since the implementation of the Enterprise PMO as compared to the number of projects completed within their budget constraints prior to the implementation of an Enterprise PMO.
Met or exceeded the customer requirements specifically identified at the beginning of the project.
Aligned with corporate strategy (Alignment should be 100%).
Have successfully been managed (on-time, on-budget, met customer expectations) after training of project managers and team members as compared to projects managed by individuals not formally trained.
Followed the prescribed Enterprise PMO project management process and were completed successfully as compared to projects that did not follow the prescribed Enterprise PMO project management process.
Applied a risk management process with fewer crisis situations, as compared to those projects that did not apply risk management.
Realized a reduction in cycle time from order to delivery or from product design to product launch.
Simplified by making transparent a complex project for the customer, supplier and third parties.
Utilized staff with appropriate skill sets for the project.
Guidelines for Structuring the Enterprise PMO
A reporting structure in which the Enterprise PMO reports directly to one or more members of the senior management team increases the likelihood for timely approvals and decisions regarding projects and generates greater visibility and acceptance for the Enterprise PMO by the rest of the organization.
Furthermore, correctly structuring the Enterprise PMO requires consideration for the authority of its leader. The head of the Enterprise PMO must have higher management level as the managers of the functional departments from which they will need to draw staff for the project team. This will help the Enterprise PMO to focus on the interests of the organization as a whole rather than on the interests of any particular functional group. It will also ensure that the Enterprise PMO is able to resolve any conflicts that may arise between projects competing for common resources.
For the Strategic Enterprise PMO, the administrator/manager of the PMO really must have the authority from senior management which is higher than departmental/divisional managers. Otherwise, experience proves that no success will be attained since each division will attempt to put up impediments to the success of any truly enterprise level project(s).
A current approach to the structuring of the Enterprise PMO is to have anyone who manages a project report to a functional manager rather than to the Enterprise PMO. Research indicates that this matrix management structure tends to reduce the hierarchy of the Enterprise PMO, and it ensures it is able to stay focused on coaching and mentoring all project managers rather than the more time consuming role of managing all project managers. This description sounds nice and it may be supported by some research; but an enterprise project (strategic or otherwise) must be led by more than a teacher or coach.
The Enterprise PMO must engage the senior management team to visibly support it and its project management approach – even in fully documented form. They can do this by coaching senior management through the approval process to ensure timely approvals are given for Project Scope Statements, Milestone Reports, Project Change Requests, and other key project documentation. As well, the Enterprise PMO should review each of these documents with the specific Project Manager to ensure that the documentation is clear and accurate before presenting it to the member of senior management who acts in the role of sponsor for the project. This ideally will reduce the need to coach the senior management on every detail of each document before they agree to its approval; but in a real world, senior management often fails to see both the business and IT side of issues and also often fails to understand most aspects of the ongoing project on either a divisional or enterprise level. This is another reason projects often fail.
It is important for the Enterprise PMO to provide early warning signs to management about difficulties that projects may be facing. While senior management does not have the time to examine individual, detailed reports on each project, they do want to be kept up to date on the progress of all projects. Therefore, it is preferable for the Enterprise PMO to maintain a regular practice of communicating and reporting to the senior management team through an integrated report that combines all projects into one report. This report will indicate which of the projects are on-track, which are off-track, and which are experiencing serious problems and/or blocks. This provides early warning signs to management of difficulties that may be occurring with any project.
“Lessons Learned” from projects and customer feedback are other forms of communication with the senior management team that will generate added support from them as continuous improvement is applied.
Summary
A PMO that is structured to manage projects across departments, locations, and countries is best implemented on an enterprise-wide basis. This is because it will hold the responsibility for ensuring consistency in the management of all elements of each of these projects and will also be able to assess and prioritize each project for alignment with the corporate strategy. The goal of an Enterprise PMO is to help their organization effectively manage projects in today’s complex, global marketplace. The successful management of these projects has a direct impact on the organization, its customers, and its resources.
There is a need for division-level PMOs; but there must also be a separately staffed and managed Strategic Enterprise PMO to coordinate all project planning, documentation, design, and implementation.
Enterprise Architecture
Although this chapter spends much of the time on the enterprise, the enterprise project, and different levels of project management, this final section is set aside for Enterprise Architecture. Enterprise Architecture must not be viewed as data architecture on steroids. Rather Enterprise Architecture must be done by one or more professionals who can see all business and technical elements on both a strategic and a tactical view.
To make any enterprise project a success it must include a key enterprise project manager, enterprise data architect, business managers, and technical managers. Each of these persons must be experienced in their respective areas, must have superior communication skills, possess a driven desire for success, and can coordinate their end of the work with everyone else.
An enterprise architecture (EA) is a rigorous description of the structure of an enterprise, its decomposition into subsystems, the relationships between/among the subsystems, the relationships with the external environment, the terminology to use, and the guiding principles for the design and evolution of an enterprise. This description is comprehensive, including enterprise goals, business functions, business process, roles, organizational structures, business information, software applications, and computer systems.
Practitioners of EA call themselves “enterprise architects” or “enterprise data architects”. An enterprise architect is not a person that is simply chosen by an executive without reason and credibility. A person responsible for developing the enterprise architecture as the enterprise architect is often called upon to draw conclusions from it. By producing an enterprise architecture, architects are providing a tool for identifying opportunities to improve the enterprise, in a manner that more effectively and efficiently pursues its purpose.
The Scope of an Enterprise Architecture
The term enterprise refers to a complex, socio-technical system that comprises interdependent resources of people, information, and technology that must interact with each other and their environment in support of a common mission.
The term “enterprise” is used because it is generally applicable in many circumstances, including
Public or private sector organizations
An entire business or corporation
A part of a larger enterprise (such as a business unit)
A conglomerate of several organizations, such as a joint venture or partnership
A multiply-outsourced business operation
Defining the boundary or scope of the enterprise to be described is an important first step in creating the enterprise architecture. It should also be noted that the term “enterprise” as used in enterprise architecture generally means more than the information systems employed by an organization.
Methods & Frameworks
Enterprise architects use various business methods, analytical techniques, and conceptual tools to understand and document the structure and dynamics of an enterprise. In doing so, they produce lists, drawings, documents, and models – individually and collectively called “artifacts”. These artifacts describe the logical organization of business functions, business capabilities, business processes, people organization, information resources, business systems, software applications, computing capabilities, information exchange, and communications infrastructure within the enterprise.
A collection of these artifacts, sufficiently complete to describe the enterprise in useful ways, is considered by EA practitioners as an enterprise-level architectural description, or enterprise architecture, for short. The best practices guidance of the UK National Computing Centre EA states that an enterprise architecture normally takes the form of a comprehensive set of cohesive models that describe the structure and functions of an enterprise.
The individual models in an EA are arranged in a logical manner that provides an ever-increasing level of detail about the enterprise: its objectives and goals, its processes and organization, its systems and data, the technology used, and any other relevant spheres of interest.
This is the definition of enterprise architecture implicit in several EA frameworks including the popular The Open Group Architectural Framework (TOGAF) architectural framework.
In 1992, Steven Spewak described a process for creating an enterprise architecture that is widely used in educational courses. [This reference is Spewak, Steven H. and Hill, Steven C. Enterprise Architecture Planning – Developing a Blueprint for Data Applications and Technology. John Wiley. 1992.]
More will be discussed on this topic in a later chapter.
Areas of Practice
Several enterprise architecture frameworks break down the practice of enterprise architecture into a number of practice areas or “domains”. In his book on Enterprise Architecture, Spewak divides the practice into multiple domains. At level 2, there are “Business Modelling”, “Current Systems and Technology”, and three subordinate domains. At level 3, there are “Data Architecture”, “Applications Architecture”, and “Technology Architecture”. The final level of Spewak’s EAP is the “Implementation” or “Methods” level, which deals with “how” to migrate the Enterprise to match the new model.
The popular TOGAF framework divides the practice into three domains: “Business Architecture”, “Information Systems Architecture” and “Technology Architecture” and then subdivides the information systems architecture into “Information Architecture and “Applications Architecture”.
The Strategic Architecture Model allows for a flexible division into up to ten domains covering many aspects of an enterprise from its objectives and goals through its projects and programs to its software applications and technology.
The dividing of the practice into a number of domains allows enterprise architects to describe an enterprise from a number of important perspectives. This practice also encourages the contributions of many individuals and allows the practice as a whole to make good use of individual domain-specific expertise and knowledge. By taking this approach, enterprise architects can ensure a holistic description is produced.
The popular and most common four domains and their component parts look like this:
Business:
Strategy maps, goals, corporate policies, operating model
Functional decompositions (e.g. IDEF0, SADT), business capabilities and organizational models expressed as enterprise / line of business architecture
Business processes, Workflow and rules that articulate the assigned authorities, responsibilities and policies
Organization cycles, periods, and timing
Information:
Information architecture – a holistic view on the flow of information in an enterprise
Metadata – data that describes your enterprise data elements
Data models: conceptual expressed as enterprise information architectures, logical, and physical
Applications:
Application software inventories and diagrams, expressed as conceptual / functional or system enterprise / line of business architectures
Interfaces between applications – that is: events, messages and data flows
Technology:
Inter-application mediating software (middleware).
Application execution environments and operating frameworks including applications server environments and operating systems, authentication and authorization environments, security systems and operating and monitoring systems.
Hardware, platforms, and hosting: servers, data centers and computer rooms
Local and wide area networks, internet connectivity diagrams
Intranet, extranet, internet, eCommerce, EDI links with parties within and outside of the organization
Infrastructure software: Application servers, DBMS
Programming Languages, etc. expressed as enterprise / line of business technology architecture.
Using an Enterprise Architecture
Describing the architecture of an enterprise aims primarily to improve the effectiveness or efficiency of the business itself. This includes innovations in the structure of an organization, the centralization or federation of business processes, the quality and timeliness of business information, or ensuring that money spent on information technology (IT) can be justified.
One method of using this information to improve the functioning of a business, as described in the TOGAF architectural framework, involves developing an “architectural vision”: a description of the business that represents a fully targeted goal. Once this vision is well understood, a set of intermediate steps are created that illustrate the process of changing from the present situation to the target. These intermediate steps are called “transitional architectures” by TOGAF. Similar methods have been described in other enterprise architecture frameworks.
Documenting the architecture of enterprises is done within the U.S. Federal Government in the context of the Capital Planning and Investment Control (CPIC) process. The Federal Enterprise Architecture (FEA) reference models serve as a framework to guide Federal agencies in the development of their architectures. Companies such as Independence Blue Cross, Intel, Volkswagen AG, and InterContinental Hotels Group have also applied enterprise architecture to improve their business architectures] as well as to improve business performance and productivity.
Relationship to Other Disciplines
Enterprise architecture is a key component of the information technology governance process in organizations such as Dubai Customs and AGL Energy. Organizations like Dubai Customs and AGL Energy have implemented a formal enterprise architecture process as part of their IT management strategy. While this may imply that enterprise architecture is closely tied to IT, it should be viewed in the broader context of business optimization in that it addresses business architecture, performance management, and process architecture as well as more technical subjects. Depending on the organization, enterprise architecture teams may also be responsible for some aspects of performance engineering, IT portfolio managemen, and metadata management.
Figure 1-2: Relationship between Enterprise Architecture and Segment (BPR) or Solution Architectures
[This
graphic was presented by Wikipedia on Enterprise
Architecture. No
date. Wikipedia.
http://en.wikipedia.org/wiki/Enterprise_Architecture.]
The above image from the 2006 FEA Practice Guidance of the United States Office of Management and Budget sheds light on the relationship between enterprise architecture and segment (BPR) or Solution architectures. (This figure demonstrates that software architecture is truly a solution architecture discipline, for example.)
Activities such as software architecture, network architecture, database architecture are partial contributions to a solution architecture.
Published Examples of Enterprise Architecture
It is uncommon for a commercial organization to publish rich detail from their enterprise architecture descriptions. Doing so can provide competitors information on weaknesses and organizational flaws that could hinder the company’s market position. However, many government agencies around the world have begun to publish the architectural descriptions that they have developed. Other good examples include the United States Department of the Interior (http://www.doi.gov/ocio/architecture/) and the United States Department of Defense business transformation agency (http://www.enterprise-architecture.info/Images/Defence%20C4ISR/Enterprise%20Architecture%20Defense.htm).
There are also models that are often used as a framework from which to start work; an example is the Trading Community Architecture model. The Trading Community Architecture (TCA) is an architecture model often used for doing ERP projects; but it is also used very often in Oracle product environments. The crux of the model is that there is a Party, which can be a person or an organization. Organizations can be broken out into Clients, Contracts, Products, Services, etc. Persons can broken out into Person_Types, etc. You can learn more about TCA and other models by using a web search of “Trading Community Architecture” or “architecture models”.
Implementations
No doubt, you have done at least one implementation of something by this time in your professional life. If you apply the following points and steps in the future chapters of this book, you most definitely had better have done many successful implementations by the last chapter!
To achieve a successful implementation, you have hopefully come to realize the critical need for preplanning, planning, documentation, concise and thorough development, equally thorough testing with review of everything from one step or phase to the next.
What Is An Implementation?
Remember that an implementation is the realization of an application, or execution of a plan, idea, model, design, specification, standard, algorithm, or policy. In computer science, an implementation is often a realization of a technical specification or algorithm as a program, software component, or other computer system. Many implementations may exist for a given specification or standard.
Also always remember not to ever do any implementation until you have done all of the preplanning, planning, documentation, development, testing, and full review. If you forget or neglect to do any step, your implementation and project will most likely fail! If you otherwise rush through an implementation, your implementation and project will also most likely fail!
An implementation failure is not an option! Implementation failures mean that one or more persons did not do their job plus it means that there will be a significant loss of time and money.
Implementation Plan
An implementation plan is a detailed project management tool for a specific policy measure or package of measures, designed to assist agencies to manage and monitor implementation effectively.
At a minimum, plans should reflect the project management standards similar to those outlined in the Guide to Preparing Implementation Plans (document included starting below).
Outline of Topics:
Project Definition
Governance
Scope/Deliverables
Implementation Schedule
Work Breakdown Structure (WBS)
Resources
Risk Management
Stakeholder Management
Quality Assurance
Implementation plans should be:
succinct, but not to the point that important information is buried
jargon free – they should be capable of being understood by everyone using them
based on a sound program logic, presenting a clear line of sight from the original proposal and the government’s expectations, to the inputs and how they will contribute to the achievement of those expectations; the outputs to be delivered; why and how those outputs are expected to deliver the outcomes sought, and the assumptions made about those links; and how this delivery chain and its supporting assumptions will be evaluated
clear on timeframes and project phases, especially where there are interdependencies with other programs or measures or critical requirements such as the passage of legislation or negotiations with the States and Territories
clear on the decision pathways forward – often both the objectives and the means to achieving those objectives are uncertain. Implementation plans need to 469odeling469 the unknowns as well as the knowns, and explain how and when the unknowns will be addressed.
Project Definition
Policy Objective/Outcome
Please outline:
the approved policy objective;
the policy context or environment, including the underlying need or problem, related policies currently in place and any previous policies, cross-jurisdictional or cross-portfolio issues, the legislative and regulatory environment, and key research and information that will influence the policy direction;
approvals to date including enabling legislation, relevant decisions by government and work already completed; and
the policy solution, delivery model or strategy for achieving the approved policy objective – this may be a brief statement of how the outputs will be delivered, how these outputs will achieve the desired outcome (policy objective) and how this outcome aligns with the Government’s strategic policy agenda, the agency’s Business Plan and outputs/outcomes framework.
Note: For Cross Portfolio Measures: where multiple agencies are involved in implementation of a measure, this section should clearly show which agencies are responsible for each aspect of the policy solution.
Benefits Statement
The purpose of this step is to describe measurable benefits expected to flow from the policy, enabling agencies to demonstrate that intended outcomes are being achieved. The Benefits Statement should provide a clear description of the intended beneficiaries and expected benefits of the policy measure. Indirect benefits should only be included if they are to be evaluated as part of the policy objective.
Please describe:
The intended beneficiaries for each policy objective as accurately as possible (noting any assumptions, constraints or exclusions).
The benefits expected to be realized by specific project/policy deliverables:
Direct benefits accrue to the intended beneficiaries of the policy such as the unemployed, small to medium size businesses, a particular environmental sector etc. Indirect benefits (or externalities) accrue to other beneficiaries such as the community and society more broadly.
Some discretion is needed to decide whether or not to include the indirect benefits of a policy measure in the benefits statement. If the indirect benefits are an important part of the policy objective then they should be included in the statement of benefits.
Couch objectives in the following terms:
Specific
Measurable
Achievable
Relevant
Time framed
Agreed
Performance measures should adopt the right fabric:
Focused on your department’s/agency’s aims and objectives, relevant to what you are aiming to achieve and the scale and complexity of the particular measure or package of measures;
Appropriate and useful for those who will use these measures. Your performance measures should clearly link outcomes to your agency’s work (establishing intermediate outcomes if final outcomes are subject to too many factors that are not directly in your agency’s control);
Balanced in their reflection of priorities and total effort;
Robust – data should be clearly defined and collected consistently, measures should be easy to understand and use, data should be collected frequently enough to track progress, and quickly enough for the data to still be useful, measures should be reliable, comparable and verifiable;
Integrated in existing performance management processes; and
Cost-effective
Many agencies have difficulty separating out the success factors for the implementation process as opposed to success in terms of a measure’s outcomes or impacts. It often happens that an implementation process is quite successful – everything happened on time and on budget – but the expectations of the government or the community were not met – in other words, ‘the operation was successful, but the patient died. The implementation plan needs to articulate a framework in which the success of the implementation process can be monitored, but it is linked to an evaluation of the overall outcomes.
Evaluation Methodology
This section should answer the question – how will we know if the policy objective has been achieved? What method will be used to measure this?
You are encouraged to consult the relevant policy area of PM&C in developing your approach to this.
Be mindful that the milestones, tracked through the Cabinet Implementation Unit reporting process, will focus on outcomes, such as the expected impacts or level of user take-up, as well as the development of products, services and programs and their roll-out.
The evaluation methodology should be designed having regard to the objectives and performance measures in your benefits statement.
The evaluation strategy should include a schedule showing when monitoring and evaluation will occur and who will be responsible for this. Where formal evaluations are undertaken, care should be taken to avoid conflicts of interest.
You may need to consider the importance of mid-term evaluations, interim progress reports or post-implementation reviews as a means of providing early feedback to government on progress towards success, and as a means of meeting accountability and transparency requirements. You may also wish to consider the adoption of internal Gateway processes as a way of ensuring continuing alignment between your project and the government’s expectations.
The development of performance indicators to measure progress, both quantitative and qualitative, should be undertaken with care. If the skills to develop performance indicators are not part of the skill set of the proposed project team, then the project manager may wish to include ‘indicator development’ skills in the ‘Resource’ section. Performance indicators may be developed for both the policy as a whole, and for each phase or activity.
Agencies should provide supporting documentation for each indicator identifying information needed, collection cost and method, frequency of reporting, validity, reliability etc.
2 Governance
This section is one of the most important in the plan, because unclear governance arrangements pose a major risk to every other aspect of a measure’s implementation. This section should never be rushed in a simple diagram – a picture cannot tell a thousand words about:
how executive support for and commitment to the implementation will be maintained and supported, the most critical element in project success
who is going to manage the various implementation processes;
who they are accountable to and what they are responsible for;
whether there are bodies outside the relevant business line, or the agency concerned, who have a formal decision-making or advisory role; how this framework will operate;
what rules and procedures for decision-making will apply.
Governance arrangements should cover all internal agency reporting lines and lines of accountability, including relevant agency boards or executive committees.
External reporting lines and accountability mechanisms should also be identified, including any relevant ministerial councils, committees, cross-jurisdictional, or cross-portfolio bodies.
This section should also identify the reporting processes in place to ensure that the sponsor and any other relevant executives are kept informed at regular intervals of progress and any issues emerging.
Please identify:
the project ‘sponsor’ – the senior executive officer within the agency responsible for ensuring delivery of the policy. Names and positions should be supplied.
the project ‘leader’ responsible for overseeing the management of implementation.
the project ‘manager’ responsible for managing operations and the project team. This person may be the same as the project ‘leader’ in some cases.
the key accountabilities – for example the sponsor may report directly to the agency head and the main executive, as well as to an internal agency executive committee, and to external advisory, or steering groups; the project manager may report to the project leader or directly to the sponsor but may also be accountable to an ad hoc working group or task force.
This may be illustrated in an organizational chart or in a table such as the following:
Table 1-1: Governance Role and Responsibilities
|
Governance Role |
Responsibility of: |
Accountable to: |
||
|---|---|---|---|---|
|
Government |
Minister for… |
COAG Working Group |
Ministerial Council |
|
|
Sponsor |
Agency, Position |
Joint Steering Committee |
Minister |
Agency CEO, Executive Board |
|
Leader |
Agency, Position |
Inter-Departmental Committee |
Sponsor |
Agency Risk and Audit Committee |
|
Manager |
Agency Position |
Project Steering Committee |
Leader |
Sponsor |
Note for Cross Portfolio Measures: Ideally, a lead agency should be agreed with a mandate for identifying a project sponsor with overall governance responsibility across agencies. At a minimum, the lines of accountability between agencies should be transparent, with the roles and membership of any steering committees clearly laid out together with the nature and frequency of reporting processes between agencies.
3 Scope/Deliverables
This section should list in tangible terms all the products and services to be delivered.
A deliverable is a measurable, tangible, verifiable output, result or item that must be produced to complete a project or part of a project.
For each deliverable, you should list the milestones that need to be achieved in order to achieve that deliverable. (A milestone is an important check point along the way that tells you if you are on track to delivery. “Establishing a section” or “having a meeting with the States and Territories” are generally insufficient indicators of progress as they say little about whether the completion of these activities contributes to the overall measure being implemented).
Every deliverable has a cost. Where possible the cost for each deliverable and milestone should add up to form the project budget.
If the project budget is a critical indicator of progress – for example, in the case of a procurement project, you should specify how the work will be done within budget and how work will be reported: for example, percentage complete, actual versus projected outlays and so on.
Your plan should also list the resources needed to achieve each deliverable.
The plan should explain what activities will be undertaken to deliver the project, and what activities the project will not be doing as well as any related activities. It defines the boundary of the project manager’s responsibility and the activities that the project manager has to undertake within that boundary with associated deliverables.
The plan needs to identify related activities that are outside the scope of the project manager, and are the responsibility of other parts of the agency or of external agencies – this is an important opportunity to establish expectations on who is doing what from the outset of the project.
A commonly used template for mapping out scope is as follows:
|
IS in Scope |
IS NOT in Scope |
Responsible Manager/Agency |
||
|---|---|---|---|---|
|
Activity |
Deliverables |
Activity |
Deliverables |
|
|
|
|
|
|
|
|
|
|
|
|
|
4 Implementation Schedule
This section should clearly outline what the project will be delivering and when. It sets the framework for dealing with the on time part of the objective, on time of the budget, and the various expectations.
The Implementation Schedule determines and defines the major phases of work that will be undertaken to achieve the desired policy objective(s) and the associated deliverables. It documents a logical sequence of events over time to progress the policy from concept to delivery. It provides a foundation for the remainder of the implementation plan, including the work breakdown structure which will detail the related activities and tasks plus the responsibilities and timeline.
For most policy initiatives, major phases of work will overlap, run concurrently, or run sequentially. Explaining these interrelationship and interdependencies is an important task for the planners. For example, development of performance measures and an evaluation strategy should proceed concurrently with other ‘set-up’ work since different skills and, therefore, people are likely to be required. On the other hand, getting guidelines or eligibility criteria approved may depend on completion of an extensive consultation phase.
Project phasing is an important way of dealing with uncertainties. For example, it is a fact of public sector life that systems development will often have to proceed in advance of all the policy issues being sufficiently nailed down to allow detailed business specifications to be developed. Similarly, issues around technology or functionality may be unresolved at the time the plan is being developed.
These are issues that need to be articulated here and in the risks section, particularly in identifying issues that are unresolved at the time – the plan needs to identify how those issues will be resolved, when, and by whom.
The Implementation Schedule should provide the following information in a clear, easy to read format:
Project Phases
Deliverables associated with each phase
Major Activities for each deliverable
Key milestones
Who is responsible for delivery of each major activity, and
Any dependencies.
You should ensure the Implementation Schedule has been checked by portfolio business and program delivery managers to ensure that targets are achievable and appropriate.
Note for Cross Portfolio Measures: A global Implementation Schedule which integrates the key activities of all the participating agencies and their sequence, together with any interdependencies, is a minimum requirement of cross portfolio Implementation Plans. Typically this is the document against which progress will be monitored and assessed for reporting through the Cabinet Implementation Unit.
5 Work Breakdown Structure (WBS)