Modeling Products and Projects

I think many PM tools suffer from the problem of conflating multiple domain models, most likely in the attempt to shoehorm them into the same tool The simple PM tools I talked about (and reviewed previously) suffer from the additional problem oversimplifying, and provide inadequate domain elements to really model the process.

I’ve come up with two (mostly) parallel models that cover the main process domains of product development. It helps me to think in terms of products and projects.

I’m not the first to make the distinction, and certainly not the first to have conflated them. Separating them and managing both in parallel helps me. I use the following two hierarchies:

Product -> Release -> Features -> Requirements

Project -> Milestone -> Tasks -> Work

Definitions and notes:

  • A product is the artifact that exists as a result of the development process.
  • A release is an iteration of the product development process tied to one or more products.
  • A feature is the implementation of one or more requirements.
    • Features may consist of sub-features or components.
  • A requirement is the definition of a business or functional needs.
    • A project is an instance of that development process, the goal of which is to deliver a product.
      • A project may have one more milestones.
      • A project has a definite start and ending
    • A milestone is an enumeration of tasks to be completed in a certain timeframe.
      • A decision needs to be made whether the timeframe or the task list determines the milestone.
        This exercise is called “scoping.”
      • The list of features defines the scope of a product.
    • A task is an element of work that needs to be accomplished.
      • Tasks may have one or more sub-tasks
      • Tasks are assigned to one person
      • Tasks also have dependencies (i.e., other tasks that must be performed first.)
        Dependencies could be an attribute, but there are potentially multiple dependencies.
        (That may just be a flaw in XML-centric thinking. I can’t think of a reason an attribute can’t be a list.)
    • A unit of work is an amount of time spent by one person on a task.
      • A task may have mutliple units of work before being complete.
      • Tasks can track estimated and actual work — measured in units of time — which can be used for time tracking and schedule planning.
        • There should be an initial and a current estimate.
        • The current estimate should equal actual work at the completion of a task

    Notes:

    Scope is the enumeration of features that will be implemented in a release.  Scoping takes into account the time required to complete the tasks required to complete each feature in a release, as well as any additional tasks (e.g., related to testing, deployment, etc.

    A deployment is a release to an environment.  E.g., deployment to test, staging, or production.

    Issues block tasks.  An issue can result in additional tasks.  It can lead to the  documentation of a defect or enhancement.

    Requirements may be separated from features.  (I can sense, based on my guidelines in the post before that my model might not be entirely correct.)  (I think the issue here is that there are mutiple meanings for the word “requirement”.)
    Catchall features such as “security” or “usability” may be used — though I don’t like that practice.
    It makes it too easy to make what should an overarching requirement into a feature that can be cut.
    I think it is better to specify the security or usability requirements for each features (and for the product in general)

    Example:

    The product is a web site. The site will be built in stages. The current release will implement several features, including a shopping cart. The shopping cart has several requirements including “ability to add products from the catalog to cart” and “credit card information will be handled securely.” These requirements may have implementation details. The difference between a business requirement and a functional requirement is whether it it tied to the implementation.

    The project is to develop the website. A milestone may the release of a set of features to production (or test). The tasks for that milestone may include implementing the shopping cart, and fixing certain existing defects.  Tasks required for completing the shopping cart feature might include design, development, testing, and deployment.

    A milestone may indicate a the completion of a stage such as planning, design, development, testing, or deployment.  Or it might mean the completion of certain features.  A release is typically a milestone.

    – I’m getting some conflation here.

    Feedback:

    I’d be curious to know if others have different ways of modeling it, or if they see flaws or advantages in what I’ve outlined.

    Thinking about development and related processes

    In my mind, product development is broken down into three stages:  design, development, and deployment.  Project management and quality assurance are supplementary activities.  Project management manages scheduling, budget, resources (people and things) and tasks.  Quality Assurance is  responsible for testing, process, and requirements management.  In general, PM interfaces with “Business”, and QA is concerned about “Customers.”  Operations handles the product after deployment.

    Model Hierarchies

    Hierarchy complexity

    Hierarchies should be 4-7 levels deep.

    Three or less is not really a model.  Ten or more is too complex.

    Two levels is really just a tuple.  Three levels is is just grouping of tuples, which doesn’t really require modeling.  Of course there are exceptions.

    Artificial Hierarchies

    You often see models (especially in XML, but also in OOP) where people sense this, and create artificial depth in hierarchies.  For example:

    <product>

    <features>

    <feature>

    <features> is just a useless wrapper around features that tells you “one or more features” may follow.  That’s really just a crutch for the parser.  You could just count up the individual <feature> element underneath <product>.

    If a featurset has attributes that can’t be expressed in the individual features, then its okay. But if it’s only a grouping, then the grouping is really just an instance of a higher level element.

    You also see a base element that is only there to have a base element.  That’s a flaw in XML, but a base element can be good for descriptive naming purposes, or to describe domain level attributes.  I think top level attributes are a bad practice though.

    Guidelines for domain modeling

    I think two common mistakes are made in modeling data & processes that can lead to unintended complexity.  The first is conflating two models that should be separate, and the second is oversimplifying models.Conflated model: when what should be two separate models are intermingled, resulting in confusing (forced) associations.  If you have two elements in a hierarchy and you’re not sure which is higher, it could be a sign of conflated models.

    Inadequate model: when the model is too simple, resulting in multiple aspects being crammed into one element — making comparison and isolation difficult.  If an element has too vague a meaning or has muliple contexts, it may be better modeled in separate elements.

    Contexts are a cood indicator of domain areas.  Requiring context to understand an element may hint at two or more models.

    Thinking about PM tools

    I’ve been thinking about Project Management tools a lot lately.

    One step I took was to try out a bunch of the new breed of lightweight tools:  Basecamp, GoPlan, ActiveCollab, ProjectPier, Wrike, etc.  I wasn’t really satisfied with any of them.  While lightweight tools are a breath of fresh air for those coming process heavy organizations, I doubt they really satisfy.  The market for simple tools is really for those who’ve never quite figured out how to implement process.  The “some process is better than no process” argument.

    But a spreadsheet beats most of those tools hands down in every aspect except distributed teams.  Sharepoint will usually handle that problem, but so would a web interface that implements the spreadsheet almost exactly.

    I’ve also tried heavy process tools such as the Rational Suite and e-Project (whatever they’re called now.)  Come to think of it, the real weight in these tools is the tools themselves.

    Clearquest’s web interface is miles better than it’s rich client, something I acknowledged a couple years ago (and the rich client hasn’t gotten any worse.)  But it’s still no fun, and you have 10 screens you need to step through to ignore 90% of it.  And integration wit Cleacase is a pain.

    The other tool,  e-Project could probably improve with a facelift, but you end up spending alot of time overriding default behaviors to allow it to be useful at all.  It’s the proverbial webified spreadsheet, only it doesn’t have the spreadsheet functionality.  Some AJAX could really help it out, but it might be too heavyweight, espcially with hundreds of tasks.

    So of course I’m thinking of a middle ground.  You want a simple enough model, but you also want tools for power users too.  You just want them to stay out of the way until needed.  The problem here is you end up bolting stuff on and it looks bolted on.  You can’t start with every feature, but starting with a good model and a reasonable (streamlined) process is important.