What's Missing from Project Management in IT

The management of IT projects is usually based on PMBOK or a similar framework. The projects start with "requirements" and add all the common processes and their outcomes. There may be a business cases, but requirements are the first step in the PMBOK paradigm.

Here's what's missing and what is needed for restore the probability of success - There is no Systems Engineering process. Systems Engineering is mentioned once in PMBOK. Capabilities is only mentioned in the context of people skills.

With both Capabilities and Systems Engineering missing, the seeds of failure are laid before the project starts.

What does this mean for the project?

• Requirements are usually gathered but rarely engineered. Engineering the requirements means
  
  • Performing fact finding.
    
    • Producing an overall statement of the problem in an operational context
    • Developing the overall operational and technical objectives of the target system
    • Define the boundaries and the interfaces of the target system
  • Gather and Classify Requirements
    • Gather required system capabilities, functional, nonfunctional, and environmental requirements, and design constraints
    • Build a Top Down Capabilities and Functional decomposition of the requirements in a flow down tree using some sort of requirements management system
  • Evaluate and Rationalize Requirements
    • Answer the question "why do we need this? in terms of operational benefits
    • Build a cost benefit / model using probabilistic assessment of all variances and dependencies
    • For technical requirements, perform a task assessment to cost and schedule
  • Prioritize Requirements
    • Determine criticality for the functions for the system mission
    • Determine trade off relationships for all requirements to be used when option decisions are made
    • For technical items, prioritize on cost and dependency
  • Integrate and Validate the Requirements
    • Address completeness of requirements by removing the TBD items
    • Validate the requirements agree and are traceable to systems capabilities, goals, and mission outcomes
    • Resolve any requirement inconsistencies and conflicts
• If these seem overly complex consider this - especially when spending other peoples money
  • If you didn't have an answer to each of these, an answer suited to the situation, then what would be missing from your ability to know what DONE looks like?
  • If you didn't have the sources of the items above, what would the customer be able to say about what DONE looks like?