...
Created 11/16/2010
Edited 11/29/2010 - brainstorming session with Amon Horne
Edited 11/30/2010 - follow-up with Bill McAvinney
CONTRIBUTING PAGES: RUNNING and REPORTING
FOR THIS DISCUSSION, assume:
- Development/Configuration projects. (i.e., not facilities, hardware rollout, VOIP, etc.)
- "Project Complexity" is not an effective measure of project cost.
- Software development process exists; i.e., this complexity study falls within any project development life cycle.
- The task is not the role. Roles may be served by the same person, or several different people.
- Everyone owns the product. The common goal is the client-identified benefit to completing the task.
hypothesis: project complexity increases the need for task GRANULARITY. task number and granularity leads to headcount. which eventually leads to defined roles.
in the task families, where do we put project management? e.g. budgeting, facilitating conversations?
Factors which increase project complexity
...
technology complexity
business complexity
invividual and team unfamiliarity with impacted systems
...
and/or the thing being built
includes development environment
...
number of business processes impacted
number of stakeholders
and also...
size of project
i.e., number of users affected, cost, etc.
...
everything below this line is in SUPERDRAFT
risk
High risk projects, i.e., those which have the potential to harm functioning processes or systems, require mitigation measures and additional documentation. If not completing the work will harm a functioning process or system, then not doing the project is similarly risky.
...