Adaptive Project Framework

The fundamental concept underlying the adaptive project framework (APF) is that scope

is variable, and within specified time and cost constraints, APF maximizes business value

by adjusting scope at each iteration. It does this by making the client the central figure in

deciding what constitutes that maximum business value. At the completion of an

iteration, the client has an opportunity to change the direction of the project based on

what was learned from all previous iterations. This constant adjustment means that an

APF project's course is constantly corrected to ensure the delivery of maximum business

value.

The core values of the APF approach are:

Client-focused

Client-driven

Incremental results early and often

Continuous question and introspection

Change is progress to a better solution

Don't speculate on the future

Agile Software Development

Agile software development is a conceptual framework for undertaking software

engineering projects. There are a number of agile software development methodologies

e.g. Crystal Methods, Dynamic Systems Development Model (DSDM), and Scrum

Most agile methods attempt to minimize risk by developing software in short timeboxes,

called iterations, which typically last one to four weeks. Each iteration is like a miniature

software project of its own, and includes all the tasks necessary to release the mini-

increment of new functionality: planning, requirements analysis, design, coding, testing,

and documentation. While an iteration may not add enough functionality to warrant

releasing the product, an agile software project intends to be capable of releasing new

software at the end of every iteration. At the end of each iteration, the team reevaluates

project priorities.

Agile methods emphasize realtime communication, preferably face-to-face, over written

documents. Most agile teams are located in a bullpen and include all the people necessary

to finish the software. At a minimum, this includes programmers and the people who

define the product such as product managers, business analysts, or actual customers. The

bullpen may also include testers, interface designers, technical writers, and management.

Agile methods also emphasize working software as the primary measure of progress.

Combined with the preference for face-to-face communication, agile methods produce

very little written documentation relative to other methods.

Crystal Methods Methodology

Alistair Cockburn developed the Crystal Methods approach. His focus is on the people,

interaction, community, skills, talents, and communications with the belief that these are

what have the first-order effect on performance. Process, he says, is important, but

secondary.

Cockburn's philosophy translate into a recognition that since ach team of people has a

different set of talents and skills which means that each team should use a process

uniquely tailored to it. And it means that the process should be minimized -- barely

significant.

The use of the word "crystal" refers to the various facets of a gemstone -- each a different

face on an underlying core. The underlying core represents values and principles, while

each facet represents a specific set of elements such as techniques, roles, tools, and

standards. Cockburn also differentiates between methodology, techniques, and policies.

A methodology is a set of elements (practices, tools); techniques are skill areas such as

developing use cases; and policies dictate organizational "musts".

Dynamic Systems Development Model (DSDM) Methodology

The Dynamic Systems Development Model was developed in the U.K. in the mid-1990s.

It is the evolution of rapid application development (RAD) practices. DSDM boasts the

best-supported training and documentation of any of the agile software development

techniques, at least in Europe. DSDM favors the philosophy that nothing is built perfectly

the first time and looks to software development as an exploratory endeavor.

The nine principles of DSDM are:

Active user involvement.

Empowered teams that the authority to can make decisions.

A focus on frequent delivery of products.

Using fitness for business purpose as the essential criterion for acceptance of

deliverables.

Iterative and incremental development to ensure convergence on an accurate

business solution.

Reversible changes during development.

Requirements that are baselined at a high level.

Integrated testing throughout the life cycle.

Collaboration and cooperation between all stakeholders.

Extreme Programming (XP) Methodology

The main goal of XP is to lower the cost of change in software requirements. With

traditional system development methodologies, like the Waterfall Methodology, the

requirements for the system are determined and often "frozen" at the beginning of the

development project. This means that the cost of changing the requirements at a later

stage in the project -- something that is very common in the real-world -- can be very

high.

XP Core Practices

The core practices of Extreme Programming, as described in the first edition of Extreme

programming Explained can be grouped into four areas (12 practices) as follows:

Fine scale feedback

Test driven development

Planning game

Whole team

Pair programming

Continuous process rather than batch

Continuous Integration

Design Improvement (a.k.a refactor)

Small Releases

Shared understanding

Simple design

System metaphor

Collective code ownership

Coding standards or coding conventions

Programmer welfare

Sustainable pace (i.e. forty hour week)

In the second edition of Extreme programming explained a set of corollary practices are

listed in addition to the primary practices.

The core practices are derived from generally accepted best practices, and are taken to

extremes:

Interaction between developers and customers is good. Therefore, an XP team is

supposed to have a customer on site, who specifies and prioritizes work for the team, and

who can answer questions as soon as they arise. (In practice, this role is sometimes

fulfilled by a customer proxy.)

If learning is good, take it to extremes: Reduce the length of development and feedback

cycles. Test early.

Simple code is more likely to work. Therefore, extreme programmers only write code to

meet actual needs at the present time in a project, and go to some lengths to reduce

complexity and duplication in their code.

If simple code is good, re-write code when it becomes complex.

Code reviews are good. Therefore XP programmers work in pairs, sharing one screen and

keyboard (which also improves communication) so that all code is reviewed as it is

written.

Testing code is good. Therefore, in XP, tests are written before the code is written. The

code is considered complete when it passes the tests (but then it needs refactoring to

remove complexity). The system is periodically, or immediately tested using all pre-

existing automated tests to assure that it works. See test-driven development.

It used to be thought that Extreme Programming could only work in small teams of fewer

than 12 persons. However, XP has been used successfully on teams of over a hundred

developers. It is not that XP doesn't scale, just that few people have tried to scale it, and

proponents of XP refuse to speculate on this facet of the process.

XP Controversy

Detailed specifications are not created or preserved.

Programmers are required to work in pairs - not all software developers expect to be

asked to work this way.

There is no Big Design Up Front. Most of the design activity takes place on the fly and

incrementally, starting with "the simplest thing that could possibly work" and adding

complexity only when it's required by failing tests. This could result in more re-design

effort than only re-designing when requirements change.

A customer representative is attached to the project. This role can become a single-point-

of-failure for the project and some people have found it to be a source of stress.

Feature Driven Development (FDD) Methodology

Jeff De Luca and Peter Coad were both greatly involved in developing the Feature Driven

Development methodology. Peter describes FDD as having "just enough process to

ensure scalability and repeatability while encouraging creativity and innovation.

More specifically, Feature Driven Development asserts that:

A system for building systems is necessary in order to scale to larger projects.

A simple, but well-define process will work best.

Process steps should be logical and their worth immediately obvious to each team

member.

"Process pride" can keep the real work from happening.

Good processes move to the background so team members can focus on results.

Short, iterative, feature-driven life cycles are best.

FDD proceeds to address the items above with this simple process (numbers in brackets

indicate the project time spent):

Develop an overall model (10 percent initial, 4 percent ongoing)

Build a features list (4 percent initial, 1 percent ongoing)

Plan by feature (2 percent initial, 2 percent ongoing)

Design by feature

Build by feature (77 percent for design and build combined)

Joint Application Development (JAD) Methodology

The Joint Application Development (JAD) methodology aims to involve the client in the

design and development of an application. This is accomplished through a series of

collaborative workshops called JAD sessions. Two employees of IBM, Chuck Morris and

Tony Crawford, developed the JAD methodology in the late 1970s and began teaching

the approach in to the 1980s.

In contrast to the Waterfall approach, JAD is thought to lead to shorter development

times and greater client satisfaction, both of which stem from the constant involvement of

the client throughout the development process. On the other hand, with the traditional

approach to systems development, the developer investigates the system requirements

and develops an application, with client input consisting of a series of interviews.

Rapid application development (RAD), a variation on JAD, attempts to create an

application more quickly through strategies that include fewer formal methodologies and

reusing software components.

Lean Development (LD) Methodology

Lean Development focuses on the creation of change-tolerant software. This

methodology embodies the notion of dynamic stability which can be thought of as similar

to how Scrum embraces controlled chaos. Bob Charette, the originator, writes that the

measurable goal of LD is to build software with one-third the human effort, one-third the

development hours and one-third the investment as compared to what SEI CMM Level 3

organization would achieve.

There are 12 principles of Lean Development:

Satisfying the customer is the highest priority.

Always provide the best value for the money.

Success depends on active customer participation.

Every LD project is a team effort.

Everything is changeable.

Domain, not point, solutions.

Complete, don't construct.

An 80 percent solution today instead of 100 percent solution tomorrow.

Minimalism is essential.

Needs determine technology.

Product growth is feature growth, not size growth.

Never push LD beyond its limits.

PRINCE2

PRINCE2 is project management methodology that takes a process-based approach. It

consists of the following 8 high-level processes:

Directing a Project:

This process defines the responsibilities of the Project Board for the project. The project

manager keeps the Project Board informed with regular reports. The board otherwise

leave the day-to day-management of the project to the Project Manager.

Planning:

Planning is a process involved throughout the project's life-cycle.

Starting up a Project:

The purpose of this process is to ensure that project is set up correctly. It is a pre-project

process that which determines if the project would be worthwhile and viable. If it is, then

it makes sense to seek commitment of resources.

Initiating a Project:

In order for a project to be approved it must be carefully planned to show how it will

meet its goals. Once planned, the project must be approved by the Project Board before

implementation can commence.

Controlling a Stage:

PRINCE2 projects are divided into stages so a project can be more easily managed and

controlled. This process covers the day-to-day management of the project by the Project

Manager.

Managing Product Delivery:

PRINCE2 is a product based system. In this context, a product can be a physical item like

a book or it can be an intangible such as a service agreement. This process creates the

products of the project and is where most of its resources are used.

Managing Stage Boundaries:

According to PRINCE2 principles, each stage must be completed and approved by the

project board before the go ahead is given to proceed to the next stage.

Closing a Project:

Another principle of PRINCE2 is that projects must be closed down in a controlled and

orderly way. This involves evaluating the project's results. Any lessons learned are

recorded, a handover document is created if necessary, and a post implementation review

is planned.

Rapid Application Development (RAD) Methodology

RAD (rapid application development) proposes that products can be developed faster and

of higher quality by:

Using workshops or focus groups to gather requirements.

Prototyping and user testing of designs.

Re-using software components.

Following a schedule that defers design improvements to the next product version.

Keeping review meetings and other team communication informal.

There are commercial products that include requirements gathering tools, prototyping

tools, software development environments such as those for the Java platform, groupware

for communication among development members, and testing tools. RAD usually

embraces object-oriented programming methodology, which inherently fosters software

re-use. The most popular object-oriented programming languages, C++ and Java, are

offered in visual programming packages often described as providing rapid application

development.

Rational Unified Process (RUP) Methodology

The Rational Unified Process attempts to capture many of modern software

development's best practices in a form suitable for a wide range of projects and

organizations. This process recognizes that the traditional waterfall approach can be

inefficient because it idles key team members for extended periods of time. Many feel

that the waterfall approach also introduces a lot of risk because it defers testing and

integration until the end of the project lifecycle. Problems found at this stage are very

expense to fix.

By contrast, RUP represents an iterative approach that is superior for a number of

reasons:

It lets you take into account changing requirements which despite the best efforts of all

project managers are still a reality on just about every project.

Integration is not one "big bang" at the end; instead, elements are integrated

progressively.

Risks are usually discovered or addressed during integration. With the iterative approach,

you can mitigate risks earlier.

Iterative development provides management with a means of making tactical changes to

the product. It allows you to release a product early with reduced functionality to counter

a move by a competitor, or to adopt another vendor for a given technology.

Iteration facilitates reuse; it is easier to identify common parts as they are partially

designed or implemented than to recognize them during planning.

When you can correct errors over several iterations, the result is a more robust

architecture. Performance bottlenecks are discovered at a time when they can still be

addressed, instead of creating panic on the eve of delivery.

Developers can learn along the way, and their various abilities and specialties are more

fully employed during the entire lifecycle. Testers start testing early, technical writers

begin writing early, and so on.

The development process itself can be improved and refined along the way. The

assessment at the end of an iteration not only looks at the status of the project from a

product or schedule perspective, but also analyzes what should be changed in the

organization and in the process to make it perform better in the next iteration.

Scrum Methodology

Scrum is an agile method for project management developed by Ken Schwaber. It's goal

is to dramatically improve productivity in teams previously paralysed by heavier,

process-laden methodologies. Its intended use is for management of software

development projects as well as a wrapper to other software development methodologies

such as Extreme Programming.

Scrum is characterised by:

A living backlog of prioritised work to be done.

Completion of a largely fixed set of backlog items in a series of short iterations or sprints.

A brief daily meeting (called a scrum), at which progress is explained, upcoming work is

described, and obstacles are raised.

A brief planning session in which the backlog items for the sprint will be defined.

A brief heartbeat retrospective, at which all team members reflect about the past sprint.

Scrum is facilitated by a scrum master, whose primary job is to remove impediments to

the ability of the team to deliver the sprint goal. The scrum master is not the leader of the

team (as they are self-organising) but acts as a productivity buffer between the team and

any destabilising influences.

Scrum enables the creation of self-organizing teams by encouraging verbal

communication across all team members and across all disciplines that are involved in

the project. A key principle of scrum is its recognition that fundamentally empirical

challenges cannot be addressed successfully in a traditional "process control" manner. As

such, scrum adopts an empirical approach - accepting that the problem cannot be fully

understood or defined, focusing instead on maximising the team's ability to respond in an

agile manner to emerging challenges.

Spiral Methodology

The spiral methodology extends the waterfall model by introducing prototyping. It is

generally chosen over the waterfall approach for large, expensive, and complicated

projects.

At a high-level, the steps in the spiral model are as follows:

The new system requirements are defined in as much detail as possible. This usually

involves interviewing a number of users representing all the external or internal users and

other aspects of the existing system.

A preliminary design is created for the new system.

A first prototype of the new system is constructed from the preliminary design. This is

usually a scaled-down system, and represents an approximation of the characteristics of

the final product.

A second prototype is evolved using four steps:

Evaluate the first prototype and identify its strengths, weaknesses, and risks.

Define the requirements of the second prototype.

Plan and design the second prototype.

Construct and test the second prototype.

At the project sponsor's option, the entire project can be aborted if the risk is deemed too

great. Risk factors might involve development cost overruns, operating-cost

miscalculation, or any other factor that could result in a less-than-satisfactory final

product.

The existing prototype is evaluated in the same manner as was the previous prototype,

and, if necessary, another prototype is developed from it according to the fourfold

procedure outlined above.

The preceding steps are iterated until the customer is satisfied that the refined prototype

represents the final product desired.

The final system is constructed, based on the refined prototype.

The final system is thoroughly evaluated and tested. Routine maintenance is carried out

on a continuing basis to prevent large-scale failures and to minimize downtime.

TenStep Project Management Process

I used to have a description of the TenStep Project Management Process on this page

having found the information I read from a book about the process to be interesting and

useful. However, I've since learned that a description of how I used the process was in

violation of the licensing terms from TenStep Inc. To be in accordance with the licensing

terms I would need to pay a fee (no idea how much).

This to me is an unusual business model as I would've thought that what I learned from a

book I paid for would be mine to use as I see fit. But the process and content aren't mine,

so I'll let the owners decide what is and isn't fair use.

So I'm retracting my endorsement of the TenStep Project Management Process as it is no

longer a good fit for how I prefer to operate. And in compliance with their terms, I will

not use the process with any of my projects. Instead, I recommend that you review some

of the other methodologies below all of which I believe are open to use by the public

(although you may need to buy the vendor's software to get the full benefit).

Waterfall (a.k.a. Traditional) Methodology

The waterfall model is a popular version of the systems development life cycle model for

software engineering. Often considered the classic approach to the systems development

life cycle, the waterfall model describes a development method that is rigid and linear.

Waterfall development has distinct goals for each phase of development where each

phase is completed for the next one is started and there is no turning back.

The perceived advantages of the waterfall process is that it allows for departmentalization

and managerial control. A schedule is typically set with deadlines for each stage of

development and a product can proceed through the development process. In theory, this

process leads to the project being delivered on time because each phase has been planned

in detail.

In practice, waterfall development often falls short of expectations as it does not embrace

the inevitable changes and revisions that become necessary with most projects. Once an

application is in the testing stage, it is very difficult to go back and change something that

was not thought of in the concept stage. Alternatives to the waterfall model include joint

application development (JAD), rapid application development (RAD), synch and

stabilize, build and fix, and the spiral model.

OPM3

OPM3 ('Operational Project Management Maturity Model') was published by the US

Project Management Institute (PMI) in 2003. It splits the broad concept of organizational

project management into three areas for systematic management: projects, programs, and

portfolios. It recognizes that organizations implement their business strategies through

projects and that, therefore, project management should be a core business capability.

OPM3 is a body of knowledge about project management best practices, and this body of

knowledge enables organizations to improve their current organizational project

management maturity. The three interlocking elements of OPM3 (knowledge, assessment

and improvement) enable organizations to assess their current state of project

management maturity and then to map an improvement path to a higher level of maturity.

Model components include best practices, capabilities, outcomes and key performance

indicators.

Managing Successful Programmes (MSP)

Programme Management, the co-ordination of a portfolio of projects that have a

strategic change impact on an organization, is of equal importance for project

management professionals. The best practice-based MSP methodology operates at a level

above Prince2 and takes in wider business topics such as strategic planning and

organizational politics. It is well described in the newly published Introduction to

Programme Management: based on MSP, which is also a brilliant resource for those

who are preparing to tackle the Foundation exam.

MSP is owned by the UK's OGC, and the APM Group runs the MSP accreditation

scheme.

PROMPT

Project Resource Organisation Management & Planning Techniques

A project management framework developed originally by the Central Computing and

Telecommunications Agency (CCTA - the civil service technical branch) in response to

an outcry that computer projects were over-running on time estimated for completion and

initial budgets as set in the Feasibility Study. Factors of double, treble and even ten-times

were experienced. PROMPT was an attempt to set down guidelines for the stage flow

through a computer project as follows:

Feasibility Study - to determine whether the project should be done/can be done/will

work if it is done.

Initial Stage - where the project organisation is set up.

Specification Stage - in which the user specification was detailed.

Design Stage - where the logical and from this the physical design of the computer

system was designed in detail.

Development Stage - The system is built and tested.

Installation Stage - The user accepts (hopefully) a working system.

Operation Stage - when the system is tuned for the work in hand.

This lead onto the development of

IDEAL

Initiation

Set context

Build sponsorship/support

Character infrastructure

Diagnostics

Characterise current and desired states

Develop recommendations

Establishing

Set priorities

Develop approach

Plan actions

Action

Create solution

Pilot and test solution

Refine solution

Improve solution

Learning

Analyse and validate

Propose future actions

BPMM

BATES Project Management Methodology

5 major planning steps as follows:

Project charter

WBS (Work Breakdown Structure)

Work package plan

Project schedule

Project budget

Prodigy

Prescribing RatiOnally with Decision-support In General practice studY

Relating to the National Health Service and medical industry. Project management group

consists of who are responsible for strategy

Project manager

Project team leader

PMO from the NHS Executive

Branch head from NHS Executive

SMO from NHS Executive

Branch head from NHS Executive

5 STEPS

5 Steps To Ensure Project Success

5-STEPS is a structured methodology designed to assist individual project teams deliver

the project on time within budget. The focus is on developing a realistic schedule for a

project and then managing it.

Each step must be validated by all participants before moving to the next step.

The 5 steps are executed sequentially in this order:

Organise the project.

Structure the process model.

Set reasonable objectives.

Gain commitment.

Manage the project.

SUPRA

The framework for SUPRA is similar to PRINCE and consists of the following:

Project organisation structure - which is broken down into:

Overall project level

Workpackage level

Technical plan.

Project monitoring and control.

Quality assurance.

Document management.

Chestra ®

Siemens Business Services Methodology Framework

Chestra Characteristics

Chestra is a Methodology Framework for the development of integrated business

solutions. The Chestra Framework covers all phases of system development. For each

phase, Chestra describes:

a process, i.e. the activities to be performed

work products to be created, i.e. the produced results

roles, i.e. the profile and responsibilities of those who perform activities

tools and techniques used for ensuring quality and productivity.

The following characteristics describe Chestra:

A Business-Process-Driven Approach

Chestra claims to treat the enterprise as the sum of its business processes. The enterprise

performance goals are translated into business process performance goals and the primary

objective of the business process design is to change the business processes until they are

able to achieve their performance goals. Then change in the domains of organization,

location, application, data and technology can serve to make the business processes

possible.

Communication and Partnership

Chestra encourages a cooperative partnership between developer and user by active user

participation at almost every step and by maintaining consensus on a daily basis.

Anticipation of Change

The business environment and user requirements are continually changing. By focusing

on broad architectures and leaving the definition of detailed requirements until the

application and system design process, thereby shortening the time interval between

requirements definition and delivery, Chestra delivers systems that more closely meet the

user's needs on the day the systems are delivered.

Model-Based Development

Model views are created for:

Business Enterprise

Business Process

Location

Organization

Application

Data

Technology

Pragmatic, Results-Oriented Methods

Chestra is designed not to conform to academic theories, but to work in practice. It seeks

and employs methods that get results. Any activity or work product that is unnecessary to

developing business solutions will be eliminated.

Chestra Phases

Vision and Strategy Phase

Architecture Phase

Development Phase

Integration Phase

Deployment Phase

Other elements of Chestra:

Chestra Proposal Management

Chestra Project Management

AIS

Administrative Information System

This Project Management Methodology consists of 7 components:

Project organisational structure.

Process.

Activities.

Prioritisation.

Resource management.

Change management.

Documentation.

Method123

Method123 is a Project Management Methodology which provides you with all of the

documents, processes, tools, templates and methods required in order to succeed as a

Project Manager. These tools are an integral part of the Method123 project lifecycle.

Project Management Scalable Methodology

Integration.

Scope.

Cost.

Time.

Quality.

Risk.

Communications.

Human resources.

Procurement.

Multi-project overview.

SDPP

Schedule Driven Project Planning

RDPP

Resource Driven Project Planning

MITP

Managing the Implementation for the Total Project

An IBM method, part of WSDDM - World-wide Solution Design and Delivery Method

COST

Customer Ownership System Teamwork

CALS

Continuous Acquisition Life-cycle System

Used in Government defence departments