Views

Enterprise:Management:Methodology

Contents

[edit]

Navigation

Home · Main Page · Enterprise  ·


[edit]

Related categories



[edit]

About the "Methodology" page

This page aims to offer an overview of popular management practices and methodology, with special emphasis on those useful in the IT domain.An excellent source for information on Management methodologies and practice is Management Help. The issues in the field of management practice are quide vast for the space available on this page. We apologize for that little information, this page is still under construction. Please stay tuned.
Image:Construction_worker.gif

[edit]

Evolutionary Project Management (EVO)

EVO is essentially an Agile Project Management methodology. EVO was framed by Tom Gilb, one of the important contributors to SEI's effort to deliver the CMM. Tom Gilb realized that the CMM processes risk to be too heavy for general adoption and proposed a 6'th lighter, CMM maturity level. His take is exposed in his "Process Out, Quality In" article (local copy). Tom Gilb coined the "Juicy Bits First" principle, which was borrowed by the Agile movement.

Here are some resources on the EVO methodology:

[edit]

Rational Unified Process

The Rational Unified Process brings together a Project Management methodology, an Engineering approach, a UML-based modeling recommended practice and the "Rational Suite" (now IBM) of process-support and design tools. The RUP has its origins in Rational's "Unified Method" of the 90's, a "merge" of the methods proposed by Rational's chief "gurus" Grady Booch, John Rumbaugh and Ivar Jacobson, with contributions from many other authors. The first step was the unification of the various modeling methods, resulting in the first version of the "Unified Modeling Language" (UML). The second step was the unification of the development and management methodologies, into the "Rational Unified Process", intended to give PMs more control over project cycle, through a variety of innovations:
  • Iterative and incremental development process, based on project life-cycle phases and milestone-delimited iterations and core workflows
  • Team-work, supported by a set of collaborative development tools, using a concurrent-design methodology.
  • Formal, use-case-driven approach to requirements definition and design, implementation and documentation, based on the UML paradigm.


The primary goal of the RUP is to support software engineers working with UML, prefferably using Rational's toolset. The name "Rational Unified Process" also refers to a set of collaborative, web-based toolset intended to enhance the intra- and inter-team communication and clarity in role and deliverable definitions. The web-based toolset allows building "Project Home" web-sites, where all procedures, project plans, role definitions, workflows and artifact documentation are made available to the team members. An extension to RUP, the "Rational Unified Process for Systems Engineering" (RUP SE) aims to bring concurrent design and iterative development to systems engineering.

[edit]

Rational RUP supporting products

Eventually,through acquisitions, Rational extended its product portfolio to encompass other processes of the project life-cycle covered by RUP:
  • Requisite Pro, for requirements gathering, analysis and management
  • ClearCase, for configuration management
  • ClearQuest, for process automation, reporting, defect and change tracking, and lifecycle traceability


[edit]

Enterprise Unified Process (EUP)

The Enterprise Unified ProcessTM (EUP) is an extension to the RUP, adding new lifecycle phases and disciplines
  • Enterprise Unified Process [1]
  • Wiki page on EUP [2]


[edit]

Resources on the Rational Unified Process

  • RUP Home Page at IBM [3]
  • Applying Rational tools to a simple J2EE-based project [4] - a 10 parts tutorial on the RUP methodology
  • Rational Unified Process Best Practices for Software Development Teams [5] local copy
  • The Ten Essentials of RUP The Essence of an Effective Development Process [6] local copy
  • Dinosaur Meets Archaeopteryx? - RUP questioning [7]
  • Process and Method - a good introduction to the Rational Unified Process [8]
  • Project Management with Rational Unified Process (RUP) [9]
  • UI RUPture - Can RUP really facilitate a better experience? [10]
  • Development of Federal Enterprise Architecture Framework using RUP [11] local copy


[edit]

Critical Chain Project Management

The Critical Chain Project Management (CCPM) is sometimes reffered to as Critical Chain Buffer Management (CCBM). It relies on E. Goldratt's Theory of Constraints (TOC). Here are some resources on the topic.

[edit]

Theory of Constraints (TOC)

The Theory Of Constraints (TOC) is an overall management philosophy whose theoretical basis was created by Elyahu M. Goldratt. The TOC assumes that an organization or project can achieve its stated goals by identifying and managing the key limiting constraints.

Here are some features of the Theory of Constraints:
  • TOC is a "Law of the Minimum", by assuming that the growth is controlled by the scarcest resource
  • TOC is based on the fact that the more constraints a system has the less stable it is
  • TOC is applicable in supply chain management, operations, logistics, syncronous manufacturing and other domains
  • TOC is also applicable in Project Management through [12] Critical Chain Project Management


The Theory of Constraints and the Critical Chain Theory are illustrated by two fictional novel written by M. Goldratt: The Goal and THe Critical Chain. TOC practitioners are entitled to certifications by TOC International Certification Organization [13]

[edit]

Critical Chain Project Management (CCPM)

Critical Chain Project Management (CCPM) is a Project Management methodology which, according to the Theory of Constraints, identifies as key limiting factor the scarcity of qualified resources assigned to the project. A project plan based on the Critical Chain methodology will put emphasis on leveling resource utilization. Compared to the Critical Path methodology, the Critical Chain introduces the resource dependencies, aggressive scheduling and safety-buffer aggregation. Rather than using the Earned Value Management (EVM) for tracking the project performance, CCPM uses buffer management, by adjusting task priorities based on buffer churn-ratios.

[edit]

Critical Chain Project Management (CCPM) resources

A few articles and informative materials describing the CCPM methodology.
  • Critical Chain Buffer Management - Taming Uncertainty in Project Operations [14] local copy
  • Critical Chain Scheduling and Buffer Management - Getting Out From Between Parkinson's Rock and Murphy's Hard Place [15] local copy
  • Critical Chain and Risk Management - Protecting Project Value from Uncertainty [16] local copy
  • Critical Chain Project Management - Coming to a Radar Screen Near You local copy
  • Developing the (Single-Project) Critical-Chain Plan - sample chapter [17] local copy
  • Critical Chain Project Management - why it delivers [18] local copy
  • A critical look at Critical Chain Project Management [19] local copy


The CCPM methodology, by dealing with resource dependencies, pooling risks in end-of-chain buffers and dynamically adjusting task priorities, is especially useful in managing enterprise-level project portfolios.

[edit]

Project Portfolio Management (PPM)

The practice of Project Portfolio Management (PPM) takes into account the inter-project dependencies caused by the sharing of scarce resources in an organization running multiple parallel projects. For this reason, PPM is sometimes called Enterprise Project Management (EPM). Effective EPM implementations are often conditioned by the introduction of the Project Management Office (PMO). The resource constraints (investment budgets, key resources, available capacity) create the need for:
  • Collaboration across all projects run in the organization to insure timely, defect-free deliveries. In fact, this creates the need for a radical cultural change within the PM staff.
  • Enterprise-level capacity planning and resource management, based on prioritization decisions, integrated delivery framework and integrated project portfolio
  • Project portfolio management, according financial evaluation criteria assessed on a per-project basis.


Overall, studies suggest that organizations implementing EPM significantly improve ROI and overall project performance metrics. In a nutshell the EPM goal is to "always doing right the right projects and only those". In order to do so, the PMO should periodically reprioritize the components of the project portfolio, reallocate resources and even shrink the portfolio by stopping projects that fail the stage-gating merit-assessment. The stage-gating process does not try to move every project forward, instead, its role is to stop the "no-merit" projects and free resources for the profitables ones. Many large, multi-project organizations implement in a form or another a stage-gating process, through which every project phase has to pass for a go/stop decision. One example is Motorola's M-Gate process. A stage-gating process has to be fair and based on clear rules that apply to all projects. The evaluation is done by gatekeeper teams. The gating process, in a sense similar to the Agile concept of sprint in SCRUM, is also a motivating factor for the project teams in-between the gates. The merit of a project passing through a gate is based on reassessing the financial parameters, by factoring-in, as weighted costs, the risks associated with the continuation of the project. In a sense, the key success factor is to manage projects like stock-market investments, based on valuation criteria. Succesful Project Portfolio Management relies on adjusting the portfolio in order to maximize its value and minimize its risk. A Dakota saying goes that "when you discover you are riding a dead horse, the best strategy is to dismount". The same can be said of how to deal with those so-called "turkey" projects. The Project Portfolio Manager should be ready for change, as a key to success. THis is not a new idea, as, acording to a saying attributed to Napoleon Bonaparte, “a battle plan lasts until contact with the enemy”. This implies a fundamental change of paradigm in Project Management, as traditional project management evolved in a "Taylorian" universe, where the stability was the norm and the outcomes were precisely predictable through thorough control of project execution. In contrast, especially in the high-tech sectors, it seems that nowadays the change is the norm, that estimates are inherently uncertain and one must "plan to re-plan", in other words the "predictive" approach has to be replaced by an "adaptive" one.

Resources for Project Portfolio Mangement

[edit]

Managing New Product Development (NPD) projects

Managing New Product Development projects is a challenging undertaking, based on a set of best practices of which some are detailed below.

[edit]

Requirements Engineering and Management

The methodologies and best practices for the Requirements Gathering and Analysis process are covered by the fields of Business Analysis and Systems Analysis Although there are many methodologies for identifying usage scenarios, decomposing complex systems and defining requirements, most are based on formal, object-oriented approaches, based on UML modeling. There are a number of good reasons making the Requirements Engineering and Management a challenging exercise:
  • The functionality of the system has to be understood before doing the actual design
  • Large amounts of information, in unexplored fields, have to be quickly gathered, analyzed and mastered
  • Hidden complexities have to be exposed and dealt with


The ISO/IEC 15504 standard on Software Process Assessment, defines the need for a Software Requirements Analysis (SRA) process in order to insure the overall capability of the Software Engineering Process. The process of Requirements Engineering and Management can be tedious and expensive if not supported by specialized tools.

Here are some resources, articles and books on Requirements Engineering and Management:
  • Volere Requirements Tools Survey and resources
  • International Council on Systems Engineering (INCOSE) Requirements Management and System Architecture Tools surveys
  • Various resources provided by Alistair Cockburn, coauthor of the Agile Development Manifesto
  • Requirements Management resources provided by Process Impact
  • Ian Alexander's page on Requirements Management
  • Hood Consulting articles on Requirements Management
  • Sophist Group resources on Requirements Management
  • Karl E. Wiegers. Software Requirements (2nd Ed.). Microsoft Press, Redmont, WA, 2005 [26]
  • Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley, Boston, MA, 2001 [27]
  • Chris Rupp and SOPHIST GROUP. Requirements-Engineering and Management (2nd Ed.). Hanser, Munich, 2002 [28]
  • How Agile Processes Can Help in Time-Constrained Requirements Engineering [29]
  • International Software Quality Institute the official German certification body for "Certified Professionals for Requirements Engineering“ (CPRE)
  • Ian Alexander's book reviews on Requirements, Systems and Software Engineering (including Fred Brooks "Mythical Man-Month")
  • Templates and Tools for Requirements Management [30]
  • Requirements Management Tools - a qualitative assessment [31] local copy
  • Documenting Requirements Traceability Information (Leino & Virve) [32] local copy
  • Methods and tools to support the ECSS Software standards [33] local copy
  • Defense Software Contractor Outpost resources on Requiremants Engineering and Management
  • Scenarios and DOORS - basic concepts local copy
  • Page of Fun about Requirements Management from Doug and Rob Rosenberg of Iconix
  • Managing the Requirements risks- resources [34]


DOORS is a Requirements Management toolset from Telelogic, being used in the organizations contracting for the defense sector. Here are some resources
  • Best Practices - Application of DOORS to System Integration local copy
  • A Hand-in-Hand Model of Primavera-DOORS integration for Project and Requirements Management [35]


Requirements gathering and analysis relies on the expertise of Business Analysts and System Analysts. Here are some resources for them:
  • A Guide to the Business Analysis Body of Knowledge (BABOK) from IIBA [36]
  • Building a Business Analysis Unit (BAU) [37]
  • Business Analyst Resources [38]


Correctly identifying the requirements and continuously checking along the whole development cycle that these requirements are fulfilled by the Engineering activities is crucial to a project's success.

[edit]

Managing inter-project and design dependencies

Many of the PM methodologies and tools (PERT, Gantt, CPM, CCPM) do not address interdependencies stemming from design complexity, e.g. feedback and iteration, all too common in Product Development. To address these issue, a complementary methodology, the "Design Structure Matrix" has evolved. The DSM method, an "Information-driven" approach to Management (IDM), complements "standard" PM methodology by identifying information flows rather than work flows. The DSM method is a matrix-based model that represents the complex interdependencies between tasks or resources, allowing for optimization by grouping and sequencing, in order to minimize risks related to feedbacks and iterations. A refinement of the DSM is the [39] methodology, developed at MIT, to systematically analyze the transformation of customer needs into functional requirements, design parameters, and process variables. The Axiomatic Design methodology is supported by tools like Acclaro, developed by Axiomatic Design Solutions Inc, who is a proponent of the Design for Six Sigma (DFSS) technology. The proposed COPE is a design-decomposition model based on the Axiomatic Design Matrices (DM). COPE aims to map the relationship between Functional Requirements (FRs) and Design Parameters (DPs), using Design Structure Matrices (DSM) to model the system development context. DSM is being applied in real life by large corporations pushing complex products to market, an example being General Motors, for Advanced Vehicle Development [40] local copy The DSM approach can mitigate the negative effects of Connway's law, which stems from the observation that design structures are constrained of and mimic the organization's functional and communication structure. However, the DSM, being a mix of engineering and management approaches to product development, might be difficult to adopt in organizations where the role and competencies of individuals and departments are clearly institutionalized.

The Design Structure Matrix (DSM) is also known as:
  • The Dependency Structure Matrix (DSM)
  • The Problem Solving Matrix (PSM)
  • Design Precedence Matrix (DPM)


Resources
  • New Product Development Body of Knowledge (BOK) [41]
  • Managing the Multi-project Environment using the Dependency Structure Matrix (DSM) [42]
  • The Design Structure Matrix (DSM) [43]
  • An Introduction to Modeling and Analyzing Complex Product Development Processes using DSM [44]
  • Product Development Process Innovation - DSM Based Process Planning local copy
  • Applying DSM to Decomposition and Integration Problems [45]
  • Overview of Axiomatic Design methodology [46]
  • Boeing's home-page for DSM
  • The Structure and Value of Modularity in Software Design [47]
  • Design Communications using the DSM approach [48]
  • A Classification of matrix-based product-modeling methods [49]
  • A DSM macro with MS Project interface [50]


[edit]

Time to Market

  • Time to Market Improvement in Product Development [51]
  • Proactive Risk Management: Controlling Uncertainty in Product Development - book [52]
  • Developing Products in Half the Time - Management's Handbook [53]
Time to market - Product Strategy, Development, Marketing and Management [54]

[edit]

Firefighting, its causes, unwanted effects and how to avoid it

  • Why Firefighting Is Never Enough - Preserving High-Quality Product Development [55] local copy
  • Firefighting by knowledge workers [56] local copy


[edit]

Knowledge management - methodology, resources and systems

Knowledge Management is a set of methodologies aimed at dramatically improving knowledge workers efficiency by enabling quick and granular access to information. Implementing Knowledge Management processes and technologies is especially important to Help-Desk operators, service providers and outsourcers.

[edit]

EVM

The Earned Value Management PM methodology was first introduced in the 60's in the US with big government contracts. It offers the advantage of tracking the advancement of a project through objective performance metrics, which simultaneously address cost, schedule and scope. As such, the EVM methodology allows to toll a project's distress bells way ahead of the due deadlines, permitting managers to timely apply preventive and corrective measures. Earned Schedule (ES) is an emerging extension to EVM, in order to improve the link between EVM and traditional time-unit-based project scheduling.
  • Earned Value Project Management in Software Projects [64]
  • Introduction to Earned Value Project Management [65]
  • US DoD Earned Value Management resources [66]
  • The EVM Community at the Devense Acquisition University [67]


[edit]

PRINCE2 methodology

The PRojects IN Controlled Environments (PRINCE) methodology is a registered trademark of the UK Office of Government Commerce (OGC)and is now at its second major version. The methodology is popular in the private sector because it follows a structured and scalable process/product-based planning approach emphasizing the use of manageable and controllable project stages.

[edit]

Effective meetings

Here are some resources on how to conduct effective meetings:

The "Focus Group" meeting uses a technique borrowed from the "Focus Groups" used in the world of marketing Here are some tips on conducting Focus Groups meetings.

A few samples of meeting document templates are available locally

Beside the "Focus Group", another useful meeting technique is Dr. de Bono's "Six Thinking Hats". The method relies on participants agreeing upon "ground rules", in order to stimulate input from more people and encourage free flow of ideas and pergormance rather than devensiveness. Each "thinking hat" has a metaphorical code-color and represents a direction or framework of thinking. For instance the white hat is for factual thinking while the red one is for intuitive, emotional thinking. A good tutorial on the methodology is available here.

[edit]

PMO

A few resources for the PMO.
  • Setting up a Project Office [73] local copy
  • The Project Management Office as an Organizational Strategy [74]
  • Project Management Toolkit courtesy of University of Minnesotta PMO [75]
  • PMOStep Project Management Office Framework [76]
  • Presentation on the benefits of the PMO charter [77]
  • PMO Charter template and example
  • The PMO challenge in the context of organizational culture [78]


[edit]

Management resources from "12manage"

  • Management by objective (SMART) [79]
  • Contingency theory - no recipes, adapt and take good decisions [80]
  • Chaos theory- applicability in business strategy [81]
  • Organizational learning strategy - increasing flexibility to change [82]
  • Boston Group DICE framework for scoring organizational change projects [83]
Retrieved from "http://www.mindtrek.dnsalias.net/components/com_mambowiki/index.php/Enterprise:Management:Methodology"