Sohodojo and Communities of the Future proudly host...
The Center for Community Collaboration Technologies
Specification Writing for Web-based
Project Planning Software

M3 deliverable: Features/Functions to be included in the Final Report

Document status: Version 1.1 - Reviewed and approved by core team, submitted 09/06/2000 for extended team review and consideration as meeting the M3 deliverable.

Authors: Jim Salmons and Frank Castellucci

Copyright (c) 2000 - Frank Castellucci and Jim Salmons, All rights reserved.

Project URL: http://sohodojo.com/techsig/project-planning-project.html

sXc Project detail: http://sourcexchange.com/ProjectDetail?projectID=24 (SourceXchange is out of business.)

Project coordination: Sohodojo

Sponsors: Position open

Sponsors (M1-3): Opendesk.com and Collab.Net

Item: Milestone 3 Deliverable
Format: Plain text file
File name: sxc24-m3-deliverable.txt - This document

1 Introduction

1.1 Purpose of this document

The purpose of this document is to establish the requirements for the design and development of the products and services of the Web-based Project Planning Software. As such, it is an evolving document reflecting the current understanding of the Project Team and the valuable feedback from users and other interested parties.

The intended audience for this Software Requirement Specification (SRS) is configuration management, project leaders, system analysts, software developers, and documentation specialists. Careful review and understanding of the SRS will ensure that the requirements outlined are correct and that the subsequent end product, the Web-based Project Planning Software system, will provide the desired level of functionality, robustness, and consistency.

1.2 Scope of the product

Today's fast-paced, dynamic world is increasingly 'project-based'. The speed and persistence of change and hyper-competitiveness of globalization have resulted in a wave of organizational adaptations which emphasize dynamic team-based responses to opportunities and challenges.

Many of today's projects have the same essential characteristics of projects of the past; omnipotent organizations wielding pools of human and other resources to perform a work-effort where 'time is money' and deadlines rule.

Not surprisingly, the currently available project planning and project management applications and web-based services offer features-sets which reflect these typical usage scenarios emphasizing financial accountability and calendar-driven schedules.

1.2.1 New-Style Projects Need New Tools

But Internet technologies were born of, and enable, a new class of project; the self-organizing, self-managing project. In this world, Communities 'own' projects rather than Companies. The 'human resources' are Free-Willed free agents rather than employees. Consensus drives more than authority. TODO goals are declared and schedules set, but the Community is at the 'mercy' of its members. Work get done because someone _wants_ to do it, not because someone has the authority to make them do it.

Many Open Source technologies are the 'evolving work product' of just such project-based, self-organizing, self-managing Communities. The requirements for a project planning and project management software solution in this 'elastic networking' world are quite different from those targeting the 'Companies, Money, Authority and Calendar'-driven project world.

1.2.2 Not to 'Fill a Void' but to Explore New Territory

As our comparative analysis shows (see Section 1.5), there is a large and growing market of project planning and project management 'web-aware' applications and web-based services. These offerings range from free to 'enterprise-priced'. A number of very credible hosted services are reasonably-priced for small team, project-specific use. These emerging hosted services could be easily-justified line-items in contract-funded Open Source development projects.

So this project is not needed to 'fill a void' by providing an Open Source offering in a space where only high-priced or closed systems dominate. Rather, our intent is to begin an Open Source-based exploration of the special needs for project planning and project management software for use in community-based, self-organizing, self-managing projects which characterize the Open Source Software development community. This focus is consistent with the goals of this project as publicly-stated by the project sponsors. (See Wish List announcement press release at SourceXchange.)

Exploring this new problem domain is a significant challenge. The budget for this project is modest. Rather than vainly attempt to specify a particular project planning software solution to address this new-style project, we intend this specification to encourage complementary explorations of this problem space by a variety of 'design and development explorers'.

Be clear, however. We are defining buildable product/service specifications. These specifications, however, are to act as a helpful guideline for solution designers. We do not want to constrain solution designers beyond what is necessary to produce a result consistent with these requirements.

1.2.3 Areas of Feature Concentration within the Final Spec

After we surveyed the comparable offerings, we asked ourselves "Which product/service features were most in need of rethinking in our community-based, self-organizing, self-managing project world?" Our 'short list' (in keeping with the budgetary constraints of this project) is as follows:

• Task Management

• Collaboration

• Requirements Management

• Template Pools

Task Management is included because this is the 'heart' of the problem space. The specifications included in this section guide the design of the 'basic building blocks' of a compliant System. Core objects such as Project Plan, Person, Role, Task, Resource etc. are defined here as well as the constraints which relate them to each other.

Collaboration is included because there are dynamics in 'new style' projects which are qualitatively different than 'old style' projects. The organic and evolutionary nature of 'new style' projects means that Project Planners are much more likely to develop a plan as a 'shared, participatory' process. And when consensus drives rather than authority, fine-grained issue management is essential.

Requirements Management is included because, 'old style or new', project success is built on a firm foundation of Requirements Development and Management. This is also the area most slighted by the current product and service offerings. Project planning and project management vendors seem content to delegate Requirements Management to specialized vendors who are skewed toward the 'enterprise-priced' side of things.

Template Pools are included because they can play a significant role in capturing and diffusing Community best practices in addition to their obvious benefits as a productivity booster.

We believe that by concentrating our requirements specifications in these four areas, we will most effectively stimulate the exploration of a new class of project planning and project management software to serve the emerging community-based, self-organizing, self-managing world we live in.

1.3 Definitions, acronyms and abbreviations

• GUI - Graphical User Interface

• SRS - Software Requirement Specification

• XML - Extensible Markup Language

1.4 References and standards

1.5 Comparative Analysis

1.6 Overview of the remainder of the document

2 General description

2.1 Product perspective

2.2 Viewpoints

2.2.1 Stakeholders

2.2.2 End-Users

2.2.3 Domain knowledge

2.2.4 System components

2.3 System architecture

2.4 General constraints

2.5 Assumptions and dependencies

3 Technical requirements

3.1 Task Management

3.1.1 Overview

Task Management codifies the Project Planning System by identifying and managing project processes, entities and attributes. It is the balancing act that keeps the process flowing by using the tools available in Task Management for collaboration, annotation, sizing, scheduling, review and acceptance, work flow, and adjustment.

Project Planning System

The Project Planning system includes the facility for describing and editing various entities that are pertinent to the objective of creating and executing a project plan. A few of the entities and processes that collaborate to define the Project Planning System typically include:

• Goals and Requirements Engineering

• Project Plan

• Tasks

• Constraints

• Resources

• Calendars

• Business Rules

• Constraint Solving (Scheduling, Resource Leveling)

• Analysis Support

• Collaborations

The remainder of this overview will address those aspects of the planning system directly addressed by Task Management.

Project Plan

The Project Plan is the formal representation of entities (tasks, attributes, and constraints) that are interdependent on other entities, said dependencies being expressed through constraints of various type and degree. The desired result of the project plan is the organization of entities that map, or lead, to the delivery or completion of something.

Task

Tasks are the decompositional, or detailed, entities that capture the step(s), typically driven by some requirement, necessary to reach a project goal. A good analogy to task decomposition is a cooking recipe: Starting with the requirement of cooking a Pasta Capri dish for guests, we accomplish the goal by breaking down the steps needed to prepare and cook the meal. This may also include non-cooking tasks, such as driving to the store and purchasing the pasta, olive oil, tomatoes, peppers, and garlic.

Tasks are adorned with attributes.

Attributes

Attributes are the properties of a task. There are work flow rules, availability, spatial, and temporal constraint attributes to consider that may effect the ability to complete a task. Just as well, there are attributes that do not constrain the team or plan in any way, examples of which include a graphical image to use when displaying the task in a GUI, or the timestamp of the tasks last modification. When attached to the task, through a property relationship, these define the attribute set of the entity. The determination of which attributes are constraining properties of the task, or project plan, and which are not, is domain defined.

Attribute Reification

The availability of attributes support capturing a relationship between entities. Allowing attributes to be attached to attributes allows the reification of tasks and other entities to the semantic expressions of the implementation domain.

Task Constraints

Task decomposition alone does not a project plan make (woof)! Constraints are those properties of an entity that capture some semantic expression as defined by the problem space domain. Constraints, reasoned with by automated or manual systems, are realized to effect the behavior of the model. Used in terms of project planning, task constraints are properties of a task that effect the delivery objective of the plan. The following are a few of the most common constraint types in serious project planning systems:

• Task to Project-Task Dependency Constraints

• Sizing Constraints

• Resource Constraints

• Calendar Constraints

• Work flow Constraints

Task to Project-Task Dependency Constraints

A task may have dependencies (or restrictions) on one or more other tasks, both in the current project plan and on those in other plans, before it can be worked on. These dependencies may force us to wait until they are completed, or we may be allowed to start work on the task when the dependencies are partially satisfied. This type of dependency introduce both a temporal change, as well effecting the level of concurrency that can be achieved in a project. Using our recipe analogy, you can't start cooking until you return from the store, on the other hand, you can prepare the marinate once the water starts boiling for the pasta.

Sizing Constraints

Another type of constraint attribute is the sizing constraint, typically captured with expressions of person hours, weeks, and sometimes month restrictions. With the ultimate goal of delivering a finished product, sizing introduces very strong constraints on the overall accuracy of the plan. At a minimum, a properly specified sizing provides a powerful temporal view for the goals. Sizing requires at least the collaboration of project management and developers to draw on experience and problem space understanding.

Resource Constraints

Resources must be available to accomplish the goals defined by a task, they just don't complete themselves. Resource constraints are expressed in terms of a resources availability. It is common that resource availability extends beyond the human software developer. Included in resource constraints are such things as hardware, network availability, and budgets. Obviously, a change in resource availability has a direct effect on the length of time to complete a task. More mature project planning systems include resource leveling technology which acknowledges the resource constraints and recalculates the delivery model.

Calendar Constraints

A related constraint to resources is the calendar constraint. When defining a project plan, you don't do so in terms of a 24x7 hour schedule, even a 8x5 model is suspect when considering sick days, holidays, or vacations of the stake-holders. Calendar constraints take part in both the overall plan, as well as the resource level of granularity.

Work Flow Constraints

Software development projects are often constrained (bounded) by acceptance and review. Risk analysis may show that, for example, the sizing of the project exceeds some finite resource (cash, developers, etc.) which render the project infeasible. Work flow constraints form a sub-event process that occurs throughout the software development life cycle. They are often expressed in terms of business processing rules and standards.

3.1.2 Functional requirements

3.1.3 Attributes

3.1.4 Other requirements

3.2 Collaboration

3.2.1 Overview

Unless it is a one person environment, collaboration is essential to a successful project. Collaborations start with the definition of the ideas and goals proposed for a new system, then continue through until the post-mortem analysis. It may take on many forms, from in-house group meetings to simple e-mail exchanges, from one-on-one telephone calls to distributed white boarding.

For the purpose of this specification, Collaborations are those interactive communication exchanges which are required by or support the 'CRUD' (creation, update, change, delete, etc.) of planning and executing a Project Plan.

Note that this System specification is NOT intended to describe the full range of collaboration exchanges and communications which are typical of a 'live project'. A LOT more communication and collaboration goes on in a project than is subject to this specification.

The Collaborations of interest here are 'project plan'-centric. The System specification describes features needed to encourage collaborative Project Plan 'plan development' as well as to address the project management side of a project including task assignment,progress reporting, plan change request and project status communications.

The emphasis in this System specification is on functions which are 'goal-oriented' and 'team-culture-oriented' rather than 'financial/budget-oriented'. This is not to suggest that financial and other resource allocation and consumption issues, etc. are not important. There are, however, a host of mature commercial products and services at a wide range of price-points, including free, which address the 'finance-driven' project world.

Community-based, self-organizing, self-managing Open Source projects (not the only kind of Open Source project, we know, but an important 'emerging' model) are much more 'people resource'-sensitive. Accommodating the 'evolutionary team' as members come and go over the life of a project is essential. Distributing operational and 'thought' leadership roles and facilitating their 'consensus-driven synergy' is essential to creative team success. Integrating 'spontaneous identification from anywhere at anytime' of what needs to be done, etc. are all Open Source project realities which must be addressed by the Collaboration functions of Systems built under this specification.

This specification's Collaboration functions emphasize 'keeping everyone on the same page' and 'sharing the page', that is, collaborative project plan development. Under this specification, the foundation of the Collaboration functions is based on the association of a flexible 'threaded messaging' facility as an attribute of a Task element at any level within a Project Plan's Task/Subtask decomposition.

This underlying messaging function is used to create a collection of Collaboration facilities including task assignment and change request negotiations, work progress reporting and, perhaps most importantly, a flexible issue tracking and resolution subsystem. To enhance collaborative plan development, it is essential that these messaging facilities can be associated as a Task attribute at any level within the Project Plan's Task/Subtask decomposition.

It is expected that there will be significant advantage in having Team Members 'tightly coupled' by sharing a 'model space' (probably a server service) in real time. The System specification does not, however, assume this level of team connectivity. It is essential that the collaboration exchanges modeled by the System provide a convenient interface for enabling and disabling standard, Internet-base email transmission of 'collaboration transaction' messages.

At the simplest level, these email messages are 'parallel tickler' notification messages. These 'low tech' messages inform, stimulate and direct the email recipient in connecting to a System service to perform or report on project activity.

At their best (which is beyond the scope of this specification), these standard email transmissions will be rich data exchanges encapsulating 'mobile task elements' which seamlessly propagate and synchronize while existing in a web of 'personal' and 'shared' model spaces. In other words, the System specification should not assume monolithic model space.

Structuring and facilitating the collaboration through a flexible threaded messaging facility is an important element of Collaboration within the System. However, it should not be underestimated how important 'dynamic status report' views are to creating an effective collaborative project work environment.

As important as project status viewpoints are to the effectiveness of a project planning system, this specification DOES NOT prescribe specific view contents. Rather, the emphasis is on specifying a flexible user-configurable view editor/reporting subsystem based on 'self-descriptive' model elements (System objects).

Time-based model element attributes are to be graphically as well as textually presented to enhance Project Plan scheduling. All model elements with time-based attributes must support a 'rendering' protocol which allows these elements to be included in static as well as dynamically-generated views. This protocol will support direct display as HTML elements as well as a 'rich data' stream, such as might be expressed in XML.

To enhance Team Member personalization, it is important that all model elements support a generalized and 'composable' state-reporting protocol. This state-reporting interface will allow the use of 'status-aware containers' (such as 'desktop folders') which serve an 'organizing, complexity-reducing' function WITHOUT HIDING the state of model elements which may be many levels 'deep' within a container hierarchy.

In summary, the Collaboration features of this System specification emphasize fine-grained (any task/subtask level) issue management and progress reporting buttressed by a flexible, user-configurable editor/reporting view subsystem.

3.2.2 Functional requirements

3.2.3 Attributes

3.2.4 Other requirements

3.3 Requirements Engineering

3.3.1 Overview

Requirements engineering is the elicitation, definition, modeling, analysis, specification and validation of what is needed from a computer system. It is a process which draws on techniques from software engineering, knowledge acquisition, cognitive science and the social sciences to improve the software engineering practice.

Requirements are defined during the early stages of a system development as a specification of what should be implemented. They are descriptions of how a system should behave, or of a system property or attribute. They may be a constraint on the development process of the system. Therefore a requirement might describe:

• a user level facility (e.g. 'the word processor must include a spell checking and correction command'),

• a very general system property (e.g. 'the system must ensure that personal information is never made available without authorization'),

• a specific constraint on the system (e.g. 'the sensor must be polled 10 times per second'),

• a constraint on the development of a system (e.g. 'the system must be developed using PHP').

Clearly, requirements are not drawn up in a vacuum. There is a tremendous amount of collaboration that takes place between system stakeholders : managers, architects, analysts, planners and, most importantly, customers.

Requirements are fundamental to the project plan. Tasks are not entered into the system unless there is a direct association to a requirement. High level tasks have a dependency relationship to the requirement they are meant to address. In a relational database, you could say that there is a foreign key relationship between a task and the requirement.

Requirements management is concerned with all of the processes involved in changing system requirements. While the definition of good requirement engineering practices is way beyond the scope of this specification, requirements management support is not.

Problems with requirements management often means that systems whose requirements do not satisfy the customer are delivered. Systems development schedules may be extended and high costs incurred for rework of the design and implementation to accommodate requirements changes. The costs of these problems in the long-term usually outweigh the short-term costs of introducing good requirements management practices.

To manage requirements, you need to maintain requirements traceability information. A requirement is traceable if you can discover who suggested the requirement (stakeholder), why the requirement exists (rationale), what requirements are related to it (dependencies, associations) and how the requirement relates to other information such as systems designs, task implementations and user documentation.

Good requirements management support is expected to include coverage for the following activities:

• Requirement elicitation. Domain defined processes that support system requirements discovery through collaboration with stakeholders.

• Requirements analysis and negotiation: Support domain defined formal negotiations processes involving different stakeholders to decide on which requirements are accepted.

• Requirements validation: Support domain defined processes which aids insure the completeness, consistency, and other business processing standards for requirement definitions.

• Requirements maintenance: Support domain defined processes for handling state changes to a requirement.

3.3.2 Functional requirements

3.3.3 Attributes

3.3.4 Other requirements

3.4 Template Pools

3.4.1 Overview

Template pools are 'piece-part' constructions of basic System object model elements, usually composed of a combination of Role, Task and Resource objects which capture a 'pattern of interaction' typical of or in a Project Plan. These patterns can be coarse or fine-grained; from a complete Project plan reusable in total, to something as fine as a simple 'submit/approve' exchange used as a 'snippet' convenience.

Template pools can be as static as a collection of 'useful examples' supplied with an initial configuration of a System, to as dynamic as a tool-assisted 'harvesting' subsystem for capturing and reusing best practices for community/team adoption.

Template pools provide a number of user benefits:

• ease new user learning

• improve experienced user productivity

• enhance reuse of Project Plans (whole and part)

• support 'model-driven' best practices

At a minimum, it is important for a System built under this specification to support Role-Task assignments which are preserved when Person actors are associated with a Role-Task assignment. Preserving Role assignments is important for dynamic view generations from both User-specific and managerial (aggregation) viewpoints.

It is even better if the Person-to-Role assignment feature supports a many-to-one association of Persons to Role with flexible allocation of Persons such as by percentage of task effort and/or time duration.

At its best, Person-Role assignments are supported at the Task level rather than at the Project level. At this fine level of granularity, the 'organic' and dynamic nature of teams on Open Source, community-based development projects would be better reflected in the System's Project Plans. This 'task-specific Role/Person association' facilitates both planning and management, but is intended to contribute best to the 'plan into action' aspect to managing a project 'according to plan'.

While these Person, Role, Task model element (System object) features are not truly specific to Template Pools, these are the characteristics of these Project Plan 'basic building blocks' that will allow Template Pools to be as powerful a feature of the System as they can and should be.

Assuming that the underlying Project Plan modeling frameworks supports the composition, storage and retrieval of such 'patterns of interaction', the Template Pools facility will provide an interface for such access to these Templates. When optionally supported, tools for the import and/or composition of these templates are tightly integrated into the Library interface. This interface should include a basic 'Roles Library' as well as a 'Task Patterns Library' where anything for a 'unary' Task to a whole Project Plan can be stored.

3.4.2 Functional requirements

3.4.3 Attributes

3.4.4 Other requirements

4 Appendices and references

4.1 List of source documents for requirements

4.2 List of related documents

4.3 History of this document

• Version 0.1 - Frank's initial cut

• Version 0.2 - Jim's additions

• Version 0.3 - Frank's addition of Requirement Engineering and format changes.

• Version 1.0 - Jim's addition of Intro comments and section 3 reordering, presented as the M3 deliverable

• Version 1.1 - Frank's added Purpose and start of acronyms, definitions, etc.

### end of document sxc24-m3-deliverable.txt ###

© 1998-2010 Jim Salmons and Timlynn Babitsky for Sohodojo excepting project web pages and documents which are published under the appropriate Open Source documentation license.
Our Privacy Statement
"War College" of the Small Is Good Business Revolution
Website design and hosting by Sohodojo Business Services,
A Portfolio Life nanocorp

[ Support Sohodojo ] [ Translate page ]
[ Search site ]