Hierarchical vs Sequential Approaches to Project Management and Implementation

    Definition of Terms

    • An account represents a company or the global entity in the customer relationship
    • A lead in an unconfirmed account/contact that is amorphous (account can be seen as a contact without an account, or an account in formation)
    • A prospect is a lead that has undergone preliminary qualification to the point where we know what we are trying to get from the relationship (opportunity)
    • A contact must exist within an account unless it is a lead (formative stage)
    • Once a lead is closed, it can be lost (remains a cold lead for later review), or it won and transformed into one or more "opportunities"
    • An opportunity is identical-to and the precursor of a project - is a project that mainly consists of the scoping, cost-analysis, confirmation -- at which point constituent tasks such as contract ratification crystallize the opportunity and transform it into an implementation project
    • A project is an opportunity with a scope, cost, and contract and it must have a clear objective (goal intention **x1 and implementation intention**x2)

    Hierarchical Project Management Approach

    1. Such a structure clearly dictates which items can be sub-sets of other items. For example, below are some of the hallmarks of a hierarchical CRM structure (especially starting from #8):
    2. A task is the do-able part of a project and cannot exist outside a project/opportunity (will be used interchangeably going forward)
    3. A task can only exist as the child of an opportunity or a project
    4. An event (meeting, phone-meeting, training) is a time-fixed collaborative occurrence that must also be part of a project as it must have a clear objective that is building towards the goal of our project
    5. A case/ticket/issue is a task that is initiated by the client with the objective of rectifying observable negative manifestations of an underlying problem

    Since tasks, events, cases are the only items that can be done, they are the only ones that can be parents of one or more timesheet entries. It is not possible to do a project (unless it is so small that it is really a task), so it does not make logical sense to associate a timesheet entry directly to a project
    This approach makes it very easy to have a top-down perspective and control system of how projects are implemented. Tasks take time to implement and thus cost money. So a task, event etc having to be placed under a project and thus justified helps keep focus on the overarching goal intention and how a given task/event/widget-cranking effort contributes to the main objective.

    Sequential Project Management Approach

    1. There is no restriction on what item can and cannot be a sub-set of another since there are no parent/child relationships by definition
    2. In the pure sense, the only relationship between items is temporal in that:
      • If a client creates a support case in reaction to an observed problem, a task, or even project can be created as a sequential result of the support case since the second item is a result of the support case.  As you can see, in the hierarchical sense, a project is here the 'child' of a support ticket
      •  If in the work process of the project and tasks described above there is need for a meeting, it to can be the child or a task under the project that is under the support case.
      • If after the said meeting there is an agenda or more things to be done, there can be further projects, tasks, etc

    The sequential process frees workers from the restrictions of a hierarchical relationship of items and processes in the Hierarchical approach to project implementation. At the same time, it suffers from ambiguity and lack of a clear understanding of the cause & effect relationship that is otherwise very clear in a hierarchical approach. Sequential project management is agile, but it can easily slip out of control and result in money and resources being spent on tasks that do not contribute to the main goal


    x1: Goal Intention - is a definition of what the intended objective of a given endeavor will be. This is a statement that defines what we want to achieve at the end of our project
    x2: Implementation Intention - is a substantiation of the goal intention and a breakdown of the goal intention into smaller implementation milestones (sub-projects), tasks, events, review tasks, etc