Good requirements are the key all projects, specially the for engineering process itself. Requirements are in terms of available capabilities. Long before the project exists, during a proposal stage, any new capabilities are researched and existing capabilities are reviewed to be considered for a potentially new project.
Emphasis is placed on ECM files containing capabilities. Once the basic capability exists, even if only planned, it can be used to propose a project.
Visibility at every level keeps projects on track. This becomes more difficult as projects grow and outsourcing plays ever larger rolls. A requirements management suite becomes required. Tracking changes and reporting to those who need to know.
Gathering all the critical requirements to avoid partial solutions. Not doing so is repeating a major issue and the first requirement below. Consider a complete scope from conception, to design, to production, to operation, return to service, to replacement. The basic requirements of an engineering process are:
How does accepting or changing a specific requirement impact the overall project scope and overall company strategy. On the other hand, how does not accepting a requirement impact the system. The process must include the impact caused to those supporting each effort. The requirement impact is the most critical part of any process.
Impact from changing priorities shall be made visible to all effected including other projects.
A requirement can not be selected without the full traceability in place. Hence, the capability must exist and its dependencies met. If capability isn't in place, there must be some research to derive the capability. Finally a capability is available for all projects.
Project schedule and cost is an integrated part of all processes. The project time line is directly connected to the project traceability. Track actual effort spent on issues, not just the charge number assigned. Consider including the all the duplicate efforts and answering the same questions over and over again.
Individual evaluations of systems need to be included for both the projects and for personal evaluation. When concerns actually materialize some credit needs to be given to those who gave the warnings.
A risk needs to be automated and part of the requirements tool. In needs to be able to support degraded operations, functionality, and risk management.
A good requirements tool shall not rule out options, but allow easy evaluation of each options. Even automate the transition of options.
Acquiring capabilities must be fully integrated into the requirements tool.
True evaluation of any source must be standardized. Whether its in house or an out sourced item.
Attach capabilities delivered to the performance record for an objective performance appraisal. Consider bonus hours for capabilities usage across projects.
Track commitments and establish bonus and penalties rules and limitations.
A reflective time tracking system is required. One that can feed the companies current system to maintain continuity. Consider a temporary system which removes several restrictions found in typical companies.
Allow individual investments in specific capabilities, so the capability is operational when requested. This allows genuine individual investments into what is needed.
Allowing bidding on suppling a capability. Allowing approved function suppliers and in house individuals equal access to needed capabilities.