How We Do Projects

Conventional wisdom says you will never reach your destination if you don’t know where you’re going. However, all too often, that’s exactly how projects are implemented. Why? The CHAOS report from the Standish Group tells us that the top two reasons are lack of user input and incomplete requirements and specifications.

To combat these negative factors, Doreen Evans Associates, Inc. has evolved an approach to projects that we’ve documented over time. We call it LINKProcess™. There are four basic principles of the approach:

(L) Lead with Business Understanding. We never launch a project without first understanding the business need that the solution is targeting and the business process it will be supporting. Our first goal is to prevent the wrong solution from being developed. Even in a systems project, it’s possible that what really needs to be changed is the process itself, or that a simple technology change such as a scanning capability can bring significant improvement. Understanding the business process provides a context for all other project work and it involves the users in helping us uncover the most critical opportunities for improvement.

(I) Identify Critical Requirements. We follow a systematic approach to identifying the requirements that the business deems important. We use repository-based tools to capture the requirements and develop the architecture (sometimes called the “meta model”) so that users of the process know exactly what needs to be documented, where it needs to be documented, and how it needs to be documented. The meta model provides a template structure that makes it easier to gather information, to build relationships among the information, and to produce project documentation based on the information.

(N) Navigate the Deliverables. We architect deliverables so that they can be used in many ways through the life of a project and beyond. For example, use cases and data models can be transferred to an object-oriented development tool to jump-start the design effort. System requirements can generate user acceptance test scripts. Business policy and business rules can be separated from other deliverables and used for development of a rules engine. Process flows can be exported to the business process management language (BPML) and used for business process management efforts, or they can help drive workflow rules.

(K) Keep and Manage a Requirements Architecture Repository System. We store all the deliverables created during our projects in a repository. This means the artifacts can:

• Be communicated to all project participants and published on the web.

• Be tracked – we know what they trace from and to, we know their change history, we know their status.

• Jump-start subsequent work. The next time a system enhancement is contemplated, you already have the requirements that represent the current system to start your work.

• Provide information to an Enterprise Architecture Repository System. Each project produces deliverables – business process maps, organization architectures - that are candidates for your Enterprise Architecture. LINKProcess includes steps to support and manage this critical aspect of the work, which we believe is a unique benefit of the approach.