Unclear Development Processes and Methodologies

There are many methodologies for IT development and implementation projects (hundreds, because many companies have their own “flavor” of a methodology or two, and maybe several) but they all should have/contain basic processes/activities: feasibility/initiation; planning; requirements analysis; design (Architecture/Detail Design); implementation/construction/build/test (unit, integration, functional\\(capability/qualification; system test (stress, functional, performance, volume, etc.); user acceptance test; operational readiness; and delivery/deployment. (Several methodologies and software control tools and applications are identified in the book and in the archived newsletters.) Many companies think their methodology is the “one” that will lead to successful projects.

What is meant by unclear processes and methodologies? Often a life cycle development process solution or approach has contained within it basic or Research and Development (R & D) processes/activities:

• concept/feasibility
• business and project planning/strategy
• requirements analysis
• design (architecture and detail design)
• implementation/construction
• testing/qualification

Production proceeds after successful development. If you include the Best Practice Processes: Project/Program Management with roles and responsibilities, the particular Development Process, Configuration Management/Deliverables (Beginning with business/product requirements) and Quality Assurance/Testing (Verification and Validation), guidelines, and templates, you have a methodology. Notice that if you include the appropriate tasks to each activity/process, you now have a task/work breakdown structure (WBS).

The above process may be planned and performed in an iterative, incremental, spiral, in parallel, or even by the waterfall development process. But a planning phase/activity should be initiated and an agreed to functional requirements specification/product description document (for an off-the shelf product) should exist before proceeding with the other processes/activities. Configuration Management (CM) is not about “freezing” (term used often in the waterfall process) the configuration. CM is about agreed to /approved baselines; document(s)/specification(s) that reflect a product. Change/Configuration Control is conducted for changes throughout the project and program. Let me make this clear, if that were not the case, you would not need/require Change/Configuration Control. Configuration Identification provides documentation from each process/activity for product/requirements/quality management and control. A baseline is a point in time for control and mutual agreement. Control for cost, schedule, and product changes (“changes in performance/capability and design”) reflected in its configuration identification documentation and the product itself, moving forward. (See S/FCM)

Examples of unclear processes/activities:

• An Envision/Initiation phase/process including within it the Requirements Analysis process/activity
• A Planning phase/process with Requirements and Architecture (design)
• A Design phase/process with Requirements and Design
• Implementation being called Production

(While knowing the above, you understand why sometimes the emphasis on identifying, defining, and specifying functional requirements required to design and implement a product, can be overlooked or ignored.)

Other examples

• Sometimes only testing is included but no Quality Assurance (QA) process (i.e. Verification and Validation)
• Sometimes on-line control (e.g., software and version control) is performed but no requirements activity/process management.
• Sometimes individuals may not understand the project management lifecycle process, considering project tools/applications (such as MicroSoft Project 98/2000, Workbench, etc.) with templates as the means to understand the life cycle process. (You also have a number of good methodologies being used (e.g., RUP, MSF, Summit, etc.)) to become familiar with the process.) Although these tools are significant, mature and useful for planning, especially in the rapid, fast-paced, development environment, they are only tools. No disrespect, but it’s like having a child use a calculator to do a math problem. Not going through or understanding the process, the child may not gain the knowledge to understand and appreciate the “process”. I have used a variety of project management and CASE tools/applications. Know and understand the process.

Many companies are to trying to establish their own independent methodology and terminology. That’s why it’s important to understand their methodology, processes and terminology but ensure the basic best practice processes/activities are tailored and used for the project or program engagement(s).