when history repeats itself itself

the memory is pure, but it’s just a flashback borrowed:
a strong link to the past, but a weak one to tomorrow.

the picture is clear, but it’s just a glimpse deranged:
nothing’s really different, yet everything has changed.

the meaning is real, but it’s just a carbon copy:
identical on the surface, but underneath it’s sloppy.

the thought is deep, but it’s just ol’ déjà vu:
ancient is the memory, but the circumstance is new.

when history repeats itself, we’re quick to place the blame,
lessons learned gleaned nothing, and time produced the same.

but take a closer look – today is not the past –
and chart a new path forward where the opportunities are vast…

“History is the only laboratory we have in which to test the consequences of thought.” – Etienne Gilson

Stop Talking & Start Digging: The Importance of Getting Dirty with Data

Today’s world can be characterized by increasing speed, complexity, disorder, and interconnectedness. For organizations trying to understand their operating environment, develop products, improve services, advance their mission, identify gaps, and support overall decision-making and strategic planning, this presents a wide array of challenges. As a result, organizational processes should be focused on overcoming these challenges and should be driven by the desire for solutions – forward-looking solutions that better understanding, improve productivity, increase efficiencies, and maximize the chance for success.

Finding or creating a solution to a complex problem requires careful planning and thought. We must beak down the problem into simpler, manageable components, identify and characterize root causes, and involve relevant stakeholders in discussions and feedback sessions. We must look across our sources of data, identify any real limitations and gaps, and plan how to execute some analytical methods across the data to extract insights. The problem is, in a world of accelerating information, needs, and problems, it’s just too easy to get caught in the planning and thinking stage. We need to get down and dirty with our data.

In the year 2011, we are surrounded by resources, libraries, catalogs, tools, and software – much of it open source and/or freely available for our own personal (AND collective) use. We must learn to access and leverage these resources efficiently, not only to perform cleansing and synthesis functions, but also to inform our collection and analysis processes to make them better as time goes on. Armed with these resources and tools, we must feel comfortable jumping right into our data with the confidence that insights will be gained that otherwise would have been lost in time.

Slicing is a helpful example of this. When faced with a high-dimension data set, usually with poorly described variables, start by slicing the data into a manageable chunk with high-powered variables – time, location, name, category, score, etc. Use a data visualization program to understand order, geospatial distribution, or categorical breakdowns. Describe the data and ask questions about how collection processes led to any gaps that exist. Simple slicing and dicing separate from the root analysis can often chart a potentially workable path forward.

The bottom line is that whether it’s dirty data or larger-scale, socially-complex problems, we sometimes need to shorten the discussion of the problem itself and get our hands dirty. Sometimes we need to create a little chaos upfront in order to shake things loose and find our intended order, structure, and path forward. After all, planning your dive is important, but sometimes you need to just dive in and see where it leads you.

Stochastic Shocks & Business Success Factors

Some events in this world are inherently unpredictable. While can hedge our bets against these events in an attempt to optimize our livelihood, sustainability, or survivability, the non-deterministic behavior of such events is a balancer of sorts – driving us to be on our toes, do good work, cherish our time, and value our lives.

In the business world, these events are often called “stochastic shocks” – events with non-deterministic behavior that affect some system, such as the economy, business growth, or personal well-being. While these do factor into business success, we can only control the risks associated with them and/or account for their potential occurrence with contingency plans and controlled reactions. We often cannot prevent them or even see them until the damage has already been realized.

Stochastic shocks aside, there are numerous controllable factors that directly contribute to the success of any business, corporation, or related organization. There must be 1,000,000,000,000,000 books and blog posts related to such “business success factors”, but through my professional experience I’d like define a few here.

Controllable Business Success Factors

The Core – Feasibility, idea completeness, relevance
Leadership – Personality, knowledge, network, approach
Strategic Planning – Objectives, milestones, foresight
Human Resources – Key performers, team dynamics, corporate culture
Customer Base – Engagement, collaboration, feedback
Market Space & Competition – Market research, competitor analysis, anticipation/reaction
Extended Social Network – Partners, public engagement, connectedness
Communication – Marketing/branding, value proposition, lexicon
Growth & Sustainability Model – Targets, thresholds, reinvestment
Corporate Posture – Adaptability, agility, dynamicity, transparency

In an effort to maximize understanding and applicability, I attempt to keep the above language and terminology as simple as possible. And while this list is neither comprehensive nor does it include evidence or examples, I’m quite sure both Google and Amazon will provide access to those 1,000,000,000,000,000 books and blog posts.

Ultimately, an optimal approach requires an organization to understand, evaluate, and measure both the stochastic shocks with non-deterministic behaviors as well as the controllable business success factors simultaneously. Understanding both sides can ensure survivability in a tumultuous world, balancing one versus the other given the available resources to do so.

Building Blocks, Foundations, & Enterprise Architectures

Languages (spoken, visual, mathematical, etc.) exist because they are the building blocks for communication, understanding, and ultimately, relationships. Relationships form the foundation for social networks, communities, strategic partnerships, and more complex systems. These systems, and the interaction of within and across such systems, is a basis for life and living.

The problem is, the definition and conceptual understanding of these building blocks, foundations, and higher-level systems often does not exist. As a result, technology development efforts, strategic partnerships, marketing campaigns, and the like suffer from a lack of true coordination and comprehension.

In general, identifying building blocks, establishing foundations, and defining more complex systems and interactions is critical to advancement in this world. In most cases, establishing these foundations is a much needed platform for coordination and comprehension that supports achievement of a higher objective. In other cases, attempting to define abstract concepts and inherently complex systems is a fruitful exercise in itself, driving constructive debate, new questions, and lessons learned for the primary stakeholders involved.

With this in mind, I seek to outline some building blocks and establish a simple foundation for enterprise architectures. My hope is that by initiating this exercise, it may provide some conceptual clarity to non-technical folks and demonstrate a framework through which other systems can be defined and explored.

The Building Blocks of Enterprise Architectures

In general, an enterprise represents people, information, and technology joined by common needs, objectives, and/or behaviors. An enterprise architecture helps define the structure of the enterprise to enable the people, information, and technology to interact in an efficient, effective, relevant, and sustainable manner.

People – Represents individuals or the various organizational constructs that contain individuals, such as a program, agency, domain, or community of interest.
Information – Represents all consumable data, products, and knowledge that is collected or created by other elements of the enterprise.
Technology – Represents the infrastructure components, networks, capabilities, systems, and programs that support other elements of the enterprise.

The Foundation for Enterprise Architectures

Now that the puzzle pieces have been broadly defined and we have a simple lexicon to work with, we seek to: (1) outline how these building blocks might fit together to support various operational needs, analytical use cases, and other tasks/functions; and (2) identify the logical connections, interactions, processes, and/or relationships between and amongst the building blocks.

The diagram below begins to define this foundation, logically placing enterprise elements (people, information, technology) to support coordination and comprehension. This would then support the examination of each possible pair of building blocks (e.g. people and information) to define the enterprise architecture and identify critical interdependencies within the system.

Enterprise Architectures: Technology Focus

To this point, establishing definitions and diagrams provides us with a core foundation for understanding end user requirements, identifying security implications, pinpointing system interdependencies, and supporting system analysis efforts. Focusing in on the technological components of our enterprise architecture, we have categorized them into three logical tiers:

Top Tier (Front-End) – Represents the technologies that support end-user interactions (data access, analysis, visualization, collaboration, input, personalization, etc) with information/data and other stakeholders.
Middle Tier – Represents the utilities, services, and support components that optimize system interactions amongst all people and information.
Bottom Tier (Back-End) – Represents the core information architecture, system security, and access / identify management components to support a secure, efficient, and effective operation.

The bottom line is that defining building blocks and outlining foundations is a critical first step to support coordination and comprehension. Sometimes just putting words and diagrams on paper saves valuable design and development hours or at least drives valuable discussion. Particularly in the world of enterprise architectures, this process is critical to align stakeholders up front and to put development efforts in perspective. Whether it’s boxes, lines, definitiosn, or discussions, sometimes a little language goes a long way.

Project Management Body of Knowledge (PMBOK) Notes – Project Management Processes for a Project (Chapter 3)

Project Management Body of Knowledge (PMBOK) Guide 4th Edition
Chapter 3 – Project Management Processes for a Project

Core Definitions

Process – A set of interrelated actions and activities performed to achieve a pre-specified product, result, or service. Each process is characterized by its inputs, the tools and techniques that can be applied, and the resulting outputs.
Project Management Processes – Ensure the effective flow of the project throughout its existence and encompass the tools and techniques involved in applying the skills and capabilities described in the Knowledge Areas.
Product-Oriented Processes – Specify and create the project’s product and are typically defined by the project life cycle and vary by application area.
Tailoring – Carefully addressing each process and its constituent inputs and outputs while managing a project.
Project Management Process Groups (or just “Process Groups”)
- Initiating – Those processes performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase.
- Planning – Those processes required to establish the scope of the project, refine the objectives, and define the course of action required to attain the objectives that the project was undertaken to achieve.
- Executing – Those processes performed to complete the work defined in the project management plan to satisfy the project specifications.
- Monitoring and Controlling – Those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes.
- Closing – Those processes performed to finalize all activities across all Process Groups to formally close the project or phase.
“Rolling Wave” Planning – Progressive detailing of the project management plan through iterative, ongoing planning and documentation efforts, usually needed due to significant changes occurring throughout the project life cycle.

Figure 1. Project Management Process Groups & Interaction Flow

General Notes

(3.0) In order for a project to be successful, the Project Team must: select appropriate processes required to meet the project objectives; use a defined approach that can be adopted to meet requirements; comply with requirements to meet stakeholder needs and expectations; and balance the competing demands of scope, time, cost, quality, resources, and risk to produce the specified product, service, or result.
(3.2) Process Groups are not project phases. As projects are separated into distinct phases or subprojects such as feasibility study, concept development, design, prototype, build, test, etc., all of the Process Groups would normally be repeated for each phase or subproject.
(3.3) Involving the customers and other stakeholders during initiation generally improves the probability of shared ownership, deliverable acceptance, and customer and other stakeholder satisfaction.
(3.3-3.7) Project Management Processes, by Process Group:

(3.3) Initiating Process Group

Develop Project Charter
Identify Stakeholders

(3.4) Planning Process Group

Develop Project Management Plan
Collect Requirements
Define Scope
Create Work Breakdown Structure (WBS)
Define Activities
Sequence Activities
Estimate Activity Resources
Estimate Activity Durations
Develop Schedule
Estimate Costs
Determine Budget
Plan Quality
Develop Human Resource Plan
Plan Communications
Plan Risk Management
Identify Risks
Perform Qualitative Risk Analysis
Perform Quantitative Risk Analysis
Plan Risk Responses
Plan Procurements

(3.5) Executing Process Group

Direct & Manage Project Execution
Perform Quality Assurance
Acquire Project Team
Develop Project Team
Manage Project Team
Distribute Information
Manage Stakeholder Expectations
Conduct Procurements

(3.6) Monitoring & Controlling Process Group

Monitor & Control Project Work
Perform Integrated Change Control
Verify Scope
Control Scope
Control Schedule
Control Costs
Perform Quality Control
Report Performance
Monitor & Control Risks
Administer Procurements

(3.7) Closing Process Group

Close Project or Phase
Close Procurements

kevin berardinelli

Month: July 2011