November 9, 2005

Organizing execution; Executing organization

Project news from industry observers like the Standish Group is riveting because we all look at projects as test cases for management practice. So when an annual survey shows even higher rates of "project failure" than were reported before our consciousness-raising, it makes us worry that our improvement efforts are not solving the right problem.

One especially acknowledged point of failure in projects is the condition of responsibility being separated from authority. Thanks to folks like Howard Fallon, we have pretty clear explanations of how organizational design is sensitive, both as cause and effect, to this problem. But what's even more interesting is the view of what a project really is, and the fact that this view is not standardized despite the exceptionally high level of disciplinary formality embedded in practice standards. The variety in the views is not within the standards, but instead in the arena where project success and failure is measured -- the business.

Illustrating the business view of "projects" starts with a shift in perspective from the project activity to the project outcome. With this business perspective, it starts to become clear that the umbrella of "projects" is much smaller than what gets evaluated.

To clarify this, first consider the semantics that should typically apply to business views of activity presumed to be flowing through projects:

Production: something produced; a work of art, etc.
Project: an organized undertaking; a special unit of work
Function: a special duty required in the course of work

Collaboration: activities interrelated for production
Coordination: activities balanced by intent
Cooperation: multiple compatible activities

Authority: ownership or control of decisions and expectations
Responsibility: ownership or control of accountability
Opportunity: ownership or control of the occasion

With that as background, consider the typical overview of the business engagement with projects.

What we know is that all major deliverables to the business are mounted within a set of "internal engineering" assumptions that have critical caveats. The management of the assumptions must recognize that just because something can happen doesn't mean that it should, and just because it should doesn't mean that it must. Seen as beneficial approaches, the assumptions must support each other through successfully balanced influences on factors they have in common, like agreements, controls and procedures. Imbalances disrupt the progress towards necessary outcomes. It's okay to see this imbalance as a description of a project failure, but what we're really looking at is a system of organizational dynamics. Within those dynamics, "projects" occupy only a certain part, as shown further below.

When a production has been ordered (requested), it issues requirements that cascade down through various levels of organization. In general, operational functions are organized into projects, and projects are organized into a production. The problem is that these elements are not self-organizing. Instead, management has to organize them end-to-end. To do this, the management levers are models and plans.

But so far this only stages the desired outcome. A crucial issue then kicks in regarding the business tolerance for accommodating the requirements, especially in light of competition from other opportunities or infirmities. Here, policies and roles express systemic management influence on eventual outcomes.

With the staging (proposal) and the tolerance (approval) established, actualization relies on sustainable commitments being made end-to-end. These commitments rely on explicit compatibilities being established with stakeholder interests. Management influence comes in the form of methods and purpose (e.g. competencies and goals) that motivate stakeholder participation:

The numerous management interventions, necessary to assure that requirements, risks and resources are aligned to the business outcome, are the critical points of success or failure and demonstrate that a project per se is largely dependent on the nurturing by its environment to survive.

Here is the overview of the prospective current state that management addresses in initially planning for progress to the business deliverables. The most important feature of this perspective is its attention to the different levels on which critical change can "naturally" occur as a result of normal everyday business activity.

In this overview, we can recognize that execution requires the alignment of requirements, risks and resources, and the adoption of that alignment shapes an organization that fosters sustainable progress.

To the extent that a project is a "micro-organization", the systemic infuences apply the same way on a smaller scale. But for the business, it is important to understand that larger scale efforts -- including initiatives, programs and strategies -- will create environments around projects that will nurture or inhibit them through the same dynamics.

For more examination of the local dynamics of execution, see our article: Why Projects Fail, in the Archestra archives.

Posted by Malcolm Ryder at 6:33 PM | Comments (0) | TrackBack

February 22, 2005

The Foundation Class Library

Archestra's knowledgebase is structured to distinguish its content as much by utility as by topic. This is an ongoing and flexible exercise that often involves identifying multiple purposes for any given item, with a fairly constant possibility of context-sensitive revisions and versions being produced.

Overall, the knowledgebase is managed by a Librarian (who you may contact via email by clicking here ).

Content contributors play key roles as follows:

Authors and Co-authors (originally conceive new work or udate their own work)
Editors (craft release-versions of authors' drafts)
Reviewers (assess relationships of new work to prior work)
Reporters (track and cite occurrences of similar or same work)

Any number of individuals may collaborate in any of those roles. Work produced from those roles is credited by role.

Posted by Malcolm Ryder at 5:01 PM | Comments (0) | TrackBack

February 19, 2005

Archestra Projects

Archestra projects basically catalog individual and collaborative efforts to add to the Framework depth and integrity in any of the following ways:

(a.) identify or propose a new structural component of a relationship in the Framework;
(b.) adjust and validate components and relationships for their integrity;
(c.) demonstrate a method for "managing" development of a component or relationship - including to define, discover, make, test, scale, position, measure, change or delete;
(d.) demonstrate similarities, affinities or integrations between the Framework and other frameworks, models and literatures;
(e.) apply the Framework to designated problems in enterprise strategy, resulting in documented application hypotheses, methodologies, or case studies.

Posted by Malcolm Ryder at 7:28 PM | Comments (0) | TrackBack