By George Pitagorsky | Follow on Twitter!
Understanding the nature of the enterprise from multiple perspectives enhances your ability to perform as effectively as possible.
Effective project and process performance relies on three pillars - people, process and tools. People, the stakeholders, do the work and receive the benefits. They play roles in the process, using tools. These three rest on a foundation that consists of mindfulness and a clear view of reality. That clear view includes an understanding of the nature of the enterprise and where in it the work at hand fits.
The Enterprise is a System
Every process occurs within a context. With projects and processes, the context is an enterprise. Making things more complex, there may be several enterprises – vendors, contractors and subcontractors and regulators all taking part in a project.
An enterprise is a system - a bounded collection of interacting people, places and things. Every system occurs within another system and interacts with yet other systems. The boundaries are made up for convenience and are subject to change. Systems are defined and described so that complex situations and their environments can be better understood.
In a system, any change anywhere can impact people and things anywhere else. Knowing the system makes it possible to predict the impact and plan the change to minimize disruption and maximize the probability of success.
What does it mean to know the enterprise?
To know the enterprise requires taking a step back to analyze it - breaking it down into its component parts - from multiple perspectives.
We can look at a system through many models or filters. One model says that a system is composed of components, relationships, properties and principles.
An enterprise architect sees the enterprise as made up of an integrated framework that links business processes to the technology that enables and supports them. This model is used as a base for process improvement - the principle reason for many projects. The enterprise architecture consists of the following:
- Business (or Business Process) Architecture – values, goals, strategy, objectives, policies, governance approach, maturity levels, organization structure, scope of operations, culture, human resource capabilities, constraints, business functions and processes, and history.
- Data Architecture – how the organization structures and manages its data and the meaning of that data in the context of the business process. A data model identifies all the people places and things of interest, the relationships among them and the data that describes them.
- Applications Architecture – the systems used in the enterprise’s processes and procedures, their interactions, and their relationships to the organization’s business processes, data and technology infrastructure.
- Technology Architecture – the technology infrastructure consisting of the software and hardware capabilities that are required to support the deployment of business, data, and application services. The technology architecture consists of IT infrastructure, hardware, operating environment, middleware, networks, communications, procedures, standards, security policies, etc.
Understanding these aspects, while maintaining a holistic view, enables project managers to make effective decisions and cultivate healthy relationships. However, as with any analysis, analysts must be aware of the tendency to think that knowing all the parts gives them the knowledge they need of the whole.
The reality is that when it comes to complex entities such as enterprises and projects, analysis reveals only part of the picture. There is still the need to step back and see the whole as more than the sum of its parts. How does it feel? How does the picture on the ground, day to day and moment to moment, match up to the picture painted by the architect? How does the process of painting and making the picture public change the enterprise?
Remember, an enterprise architecture description is a model. A model is not the thing it describes. Though, it can be refined over time to be increasingly closer to a true picture.
How an Enterprise View Helps
Knowing the characteristics of the enterprise enables stakeholders to perform optimally by aligning with enterprise goals and objectives and adapting to constraints, cultures, values, the current state of process and technology maturity, knowledge, resource capability, and style.
For example, a project manager from a consulting firm engaged in a project at a firm that has a low level of project management maturity will be more likely to moderate his or her PM approach if aware of the maturity level. Going in blindly, assuming that everyone knows how to manage projects in a professional way (whatever that means) can lead to unmet expectations and unnecessary conflict.
A project team responsible for re-engineering a business process risks failure if it doesn't take the time and effort to know the nature of that process and the enterprise it is a part of before making a plan to change it.
A PMO manager implementing a PM tool set does well to understand the enterprise’s technology architecture, attitudes about accountability, history of prior attempts and PM maturity before choosing a tool and planning its implementation.
Change makers initiate change. Project managers and performers are change agents who implement change. An enterprise view enables change makers and change agents to better predict reactions to change initiatives and plan them in a way that improves the probability of success.
Questions or comments? Feel free to share them below!
You may also like: