Tuesday, January 24, 2012

The Project Management Office

For years, IT departments have struggled to deliver projects on time and within budget.  Technology is not always the most critical factor.  Inadequate project management implementation constitutes a third of project failures, while a lack of communication and an unfamiliarity with scope & complexity constitutes another 40%.  Accordingly, 70% of project failures are due to lack and/or improper implementation of project management methodologies.  As the discipline of project management has become more recognized as a unique and valuable skill set in industry, and as companies seek more efficiency and tighter monitoring of IT projects, most companies end up opening project management offices (PMO). 

A project management office (PMO) is an organizational body or entity assigned various responsibilities related to the centralized and coordinated management of the projects under its domain.  The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of a project.

The projects supported or administered by the PMO may or may not be related, and the specific form, function and structure of the PMO is dependent upon the needs of the organization.  A PMO may be delegated to act as an integral stakeholder and key decision maker during the beginning of each project, to make recommendations, and to terminate projects or take other actions required to keep business objectives consistent. 

A primary function of a PMO is to support project managers in a variety of ways, which may include:
  • Managing shared resources across all projects administered by the PMO
  • Identifying and developing project management methodologies and best practices
  • Coaching, mentoring and training of project management resources
  • Monitoring compliance with project management standards, policies and procedures
  • Developing and managing project policies, procedures and other shared organizational process assets
  • Coordinating communication across projects

All these efforts are aligned with the strategic needs of the organization. Coming up with a PMO that works for any given organization is an exercise in both customization and patience. When it comes to establishing a PMO, there are no road maps to follow, benchmarks to shoot for or metrics against which to measure. The most effective PMOs are those that reap improvements over time and continuously push the IT department to improve on its performance

Monday, January 16, 2012

SWOT Analysis

Another important tool in the Business Analysts arsenal, used to quickly analyze various aspects of the business process or system undergoing change, is the SWOT Analysis
  • Strength
  • Weakness
  • Opportunities
  • Threats
Since a large part of my work has been in the corporate performance management arena, the SWOT Analysis is something I've used often as a framework for strategic planning, opportunity analysis, competitive analysis and business development. 

The steps to conduct a SWOT analysis are as follows:
  • Draw a grid or matrix
  • At the top of the grid/matrix, describe the topic or problem under discussion
  • Conduct a brainstorming session to complete each section of the grid
    • Strengths: any internal factor that the assessed group does well.  It may include anything such as effective processes, experienced personnel, low prices and customer relationships
    • Weaknesses: any internal factor that the assessed group does poorly (or not at all)
    • Opportunities: external factors that assessed group may be able to take advantage of, including new markets, new technology etc...
    • Threats: external factors that can negatively affect the assessed group, including entrance into a market of a new competitor, economic downturns etc...
  • Facilitate a discussion and analyze the results
  • Brainstorm potential solutions to solve the problem (compare strengths & weaknesses against opportunities & threats)

Monday, January 9, 2012

Data Flow Diagrams & Data Models

In the engineering, technology and system development world, a model is anything used in any way to represent something. Some models are physical objects.  For instance, a toy model which may be assembled, and may even be made to work like the object it represents. Other models are conceptual models, and are used to represent concepts and/or processes which are part of a system. Each of these types of model is used to help us know and understand the subject matter we are trying to represent.

There are a number of visual and descriptive techniques used by software engineers and business analysts to model the “as is” and “to be” nature of the system they are analyzing. An earlier post of mine discussed two such models: scenarios and use cases.  In this post I'd like to discusses two other popular modeling technique: data flow diagrams & data modeling.

Data Flow Diagrams provide visual representations of how information moves through a system.  They are used as part of an overall structured analysis approach for converting business requirements into design specifications, and are typically used as a prerequisite activity to data modeling.  Data flow diagrams give the business analyst and software programmers a better understanding of the actors and processes involved in a system by showing:
  • The external entities that provide data to, or receive data from, a system
  • The processes of a system that transform the data
  • The data stores in which data is collected
  • The data flows by which data moves between each of the 3 items above


A data model is used to describe the concepts relevant to a domain, the relationships between those concepts and the information associated with them.  It usually takes the form of a diagram supported by textual descriptions, used to visually represent the types of people, places and things that are important to the system.  While the data flow diagram describes how the data & information flows within a system, the data model is used to better describe the actual data within that system.  Logical data models describe the information relevant to the organization, while physical data models descirbe how data is stored and managed in a software application (i.e. the data store). 

Below is the visual representation of a simple data model that could be used to store demographic information about people living in a city:


Wednesday, January 4, 2012

Corporate Performance Management vs. Business Intelligence

Based on a recent survey by the Gartner Group, Business Intelligence (BI) analytics and Corporate Performance Management (CPM) have been a top prioriy for Chief Information and Chief Financial officers for over 4 years.  Analyzing and enhancing corporate performance is important because it can help organizations find bottlenecks & inefficienes and help exploit areas that are profitable.

As I've discussed before, Corporate Performance Management is the process of managing an organizations strategy, and describes the methodologies, metrics, processes and systems used to monitor and manage a company's business performance.  Business Intelligence is an analytical process that produces insights, suggestions and recommendations for the managerial decision makers.

While both terms are used synonymously, they are different.  As a concept, CPM represents the strategic deployment of Business Intelligence solutions.  BI provides the backbone for CPM. BI is an enterprise information platform for querying, reporting and analyzing performance. It involes grabbing raw data from disparate source systems and integrating it into a data warehouse.  CPM is about leveraging that information in a meaningful way, in an effort to drive & measure corporate performance and decision making.

Strategy
BI: Offers the tools necessary to improve decision making, but not necessary linked to organizational strategy
CPM: linked to strategy through KPI's

Purpose
BI: Helps the organization gather relevant data (bottom up approach)
CPM: Helps the organization compare data to organizational goals (top down approach)

Scope
BI: One more departments or functional areas
CPM: Enterprise wide

Orientation of application
BI: reactive (analyzing past performance)
CPM: proactive (planning for future)