Objectives
The path from requirements to deployment is seldom straightforward or immune to hazards. All too often expectations and commitments cannot be fully set upfront and must be progressively refined, tuned, corrected, and even abandoned. That make project management a continuous endeavor combining estimation and planning with monitoring and arbitrage.
A Time for Every Purpose
Things may happen by chance but won’t last without a reason; as a corollary, project management is about assigning time depending on purpose:
- Business time is for requirements and is set by enterprise strategy and markets opportunities.
- Systems time is set by organization and systems functionalities.
- Development time is set by projects schedules, technologies and resources.
Whereas those time-scales are to be synchronized (that’s what milestones are about), there is no reason they would be congruent. And they shouldn’t be because they are set within different architectures: enterprise, functional, and technical.
Project management should therefore be explicitly organized along those different time scales in order to support collaboration and arbitrate between conflicting schedules.
That should be one of the benefits of the MDA framework with CIMs, PIMs, and PSMs respectively used to anchor business, system, and developments times. One step further, with project defined by models, they could be priced and contracted out according targets and reuse of existing processes,functionalities, or components.
Project Participants
Project roles and responsibilities can be defined by task or organization.
With regard to the nature of tasks, skills and responsibilities can be organized along two dimensions:
- Purpose: management of shared assets (architects) vs specific requirements (analysts).
- Target: enterprise vs information systems.
With regard to organization, and beyond the specific methods and project, some basic roles can be identified depending on their situation regarding (1) the Customer/Provider divide and (2) the application life-cycle.
- On the customer side, stakeholders manage objectives, budgets, and schedules, users detail requirements to be formalized by business analysts. IT services take charge of deployment while acceptance may be performed by users, analysts, and IT services.
- On the provider side, project managers define work units, resources, and schedules, system analysts specify functionalities and architectures, developers are in charge of design and implementations. Quality may be managed by analysts, developers and dedicated teams.
Guidelines
Usually, system engineering is understood in terms of large applications combining software and hardware. Legacy systems are introduced at implementation level, and maintenance dealt with by subsequent tasks.
That view works fine with standalone applications. It falls behind when there is no waterproof cordon between existing and planned systems, but a motley of heterogeneous components each with its own life cycles. In that case projects can hardly be seen as discrete, steady, and independent undertakings, but rather as a continuum of overlapping requirements subject to periodic adjustments.
Given a set of business requirements weighted by benefits and risks, the first step is to commit and profile requirements depending on their footprint and horizons; that cannot be achieved without a clear understanding of dependencies between requirements and system architectures, and that will required layered traceability.
Once requirements duly profiled and tracked, it’s possible to select processes and build projects accordingly: define work units, set metrics for deliverables and workload, plan for quality and reuse.
On a broader perspective, the Caminao approach provides a principled support for the design and assessment of development processes along the Capability Maturity Model Integration guidelines.
Due Diligence
Like any human endeavors, projects may fail for multiple reasons, some external, some internal. But no project should fail from a lack of due diligence, more precisely, participants should:
- Say what they know, mean what they say, say what they mean.
- Look at outcomes and deliverables, and check their validity.
- Listen to what others have to say, and take their concerns into account.