By: Coad Letter Process Editor
Abstract: In this issue, we'll look at a process paradigm that I coined a year or so ago.
Most development projects have a sense of what needs to be built, and
the time frame in which the finished product is desired. Pretty simple,
Most development projects also miss both of these goals. But, we all knew
that line was coming. (I "set you up" on that one.)
Coming from the Department of Defense (DoD) professional engineering services
world (1986-1995), I had been an early user of project planning tools (DOS-based
Harvard Project Planner might have been my first "real" tool).
I learned about PERT charts, and Work Breakdown Structures (WBS), and Gantt
charts (always hard to spell!). I also became quite adept at recognizing
the underlying subtlety: there is actually an algorithm running behind the
scenes of these graphical tools!
To make customers and managers happy, I would back up my engineering project
estimates with carefully laid out project plans. From the end goal,
I would work backwards with an assortment of tasks, breaking down the various
work steps (hence, the term WBS). Turning these activities into a network
of dependencies (that is, Task 27 must preceed Task 42), applying estimated
durations, and adding any desired milestones (for example, preliminary design
review), I formed the PERT chart (also known as, Network Diagrams, Precedence
Diagrams). From a point of view of Critical Path Management (CPM), most
tools were able to adroitly produce the ever-popular Gantt chart, making
some tasks serial while others were able to be run in parallel. The Gantt
chart resulted in showing the tasks as a function of calendar (usually "Days
from Start" for estimates, and actual dates for live plans). I even
began to get fancy with lead-lags, ALAP (versus the default of ASAP), resource
leveling, and baselining.
An interesting lesson I learned was that many people wanted a Gantt chart
for their project plan, but did not want to adhere to the rules of the PERT/CPM
algorithms. Folks just wanted a "pretty picture." This happened
so often that I found a simple Gantt tool that these folks could use to
just draw the picture.
These always looked great in a proposal! Multi-year wall charts. Amazing
to be able to predict out the future to such a degree! Whoo-hoo!
In virtually all business pursuits--including application development--there
are desired goals. These are usually higher-level abstractions, and
are of more interest to the stakeholders than to the average project team
member. Also, in virtually all business pursuits--including application
development--there are (or at least should be) desired best practices
(processes) to achieving the goals.
Goals--which play a crucial role in business processes--can be thought
of as follows:
Processes can be things like:
In these types of goal-driven processes, the goal is the leading entity
around which resources and tasks and plans are set into motion. It is also
the basic entity by which progress can be measured easily. In FDD, a list
of prioritized features are developed early on and used to guide the tasking
and scheduling of the team. In the SCR process, the Change Request is either
a new feature or a bug, or is for current release or a future release--all
of which combine to determine when the team will be working on the request.
In XP (like FDD), the User Stories are prioritized and used to closely steer
the team's efforts in small time blocks.
For some reason (likely my familiarity with a given tool and process),
I began my first software projects in the same manner that I had learned
to do engineering projects: attempting to predict the tasks that I would
do to build out the application. I would assign costs to resources, and
resources to tasks, providing a cost roll-up as a byproduct of the project
plan. Unfortunately, as software grew more and more complex, this technique
began to be less and less effective. That is, the classic dilemmas that
all software projects face these days--for example, ill-defined requirements,
changing requirements, dynamic business environment--began to make the
relatively static project plan difficult to maintain, and woefully inaccurate.
In a typical software development Gantt chart, the large majority of the
tasks are of no interest to the client, but the milestone dates are important.
Conversely, the detailed tasks are likely of great interest to the development
team. I began to notice this dichotomy, or duality of purpose, in the project
plan's usage. I also did not like the non-adaptive nature of a project plan.
That is, it was not easy to provide the following:
The first element applies to basic project estimation rules. One often
has a best case, most likely case, and a worse case scenario--some type
of statistical variation on the basic plan. This can even be applied at
the low-level task, as needed, and the results reflected in the higher-level
roll-ups of tasks. Most Gantts that I have seen guiding projects just stick
with a single set of deliverable dates.
The ability for a project to have "if-then-else" logic is typically
not available in the form of a Gantt, yet almost all processes have decision
points with 2 or more branches.
The lack of "auto update" of task status requires manual labor
to update the project. MS Project Server now offers a means for a team to
keep the project and tasks up to date. (I have not tried it, only read about
it.) Naturally, if you want to use a Gantt to show status, you can likely
do a simple ROI calculation on the cost of maintaining the project's accuracy
versus the cost of the Project Server system.
The following figure shows a sample process with some decision blocks:
Figure 1: A sub-process for determining if a requirement
(user story) meets the needs of the process.
If your process contains branches (such as in Figure 1), how would you
provide an estimate or use a Gantt representation? If your development process
does not contain branches, I'd love to hear about it!
Have you ever done a +/- 30% estimate? Ever apply it to a Gantt (fuzzy
How accurate are the far-term tasks on any Gantt you have seen?
In general, if you have to make a Gantt for estimation purposes, I recommend
Using a goal-centric approach for software development, you can follow
XP and FDD style of project planning. First determine the basic high-level
schedule goals (usually the stakeholders have an initial desired goal--it
may or may not be realistic, time will tell). Then determine how long your
iterations will be--for example, say you decided to build a usable version
of the product every 3 weeks, and deliver a beta release in 6 months, with
a version 1.0 release one month after that. Then, you can do the following
with each feature request in your list of features (also, use this process
as new feature requests arrive):
Figure 2: High-level view of initial handling of a new
In general, paying attention to only the scheduling of the "Goal"
(feature, user story, use case) per unit of development time, you can simplify
your project estimation tasks.
If you haven't had the joy of working with a Gantt-style project plan that
has thousands of tasks, well... consider yourself fortunate. The challenge
of assigning each task is tedious (as it is often a manual process to map
a project team member to the task). Once the project tasks are started,
updating the status of each task is yet another highly tedious task. What
about working on a task that needs to be done yet was not thought of when
the plan was laid out? A progressive project manager will allow the project
to be amended. However, sometimes, when the cost of making such a project
change is too huge, the "unforeseen" tasks often just get done
and not recorded--to the detriment of all:
Of course, to a large degree in a software project, the tracking of fine-grained
tasks is not nearly as important as the completion of tangible results.
For example, the completion of a feature or a user story such that customer
sign-off is now required. The completion of each "goal" is what
The Gantt chart is a very visual reporting tool loved by many. Indeed,
it has an excellent reputation for being an easy-to-read view of the project's
timeline. Gantt charts are an excellent means to show task planned versus
actual, actual time spent versus estimated duration, and so on.
However, in the spirit of eXtreme Programming and Feature-driven Development
(et al), it is sufficient to anchor the reports to the status of the stories
or features. From the stakeholder's perspective, a simple tabular listing
of features and their current state, plus a trend chart showing planned
application feature growth versus actual, will provide an instant view of
the status of the overall project.
In Goal-centric Project Management, project status is comprised of a simple
list of goals and their status. For example:
Naturally, it is also pretty clear that one could take this information
and present it in the form of a Gantt chart. It just so happens that--unless you record actual start and stop times on a given feature--the
Gantt chart won't be too complex in terms of serial tasks.
If you are struggling with driving your development process with a traditional
MS Project/Gantt-style planning mindset, why not try Goal-centric Process
and Project Management on your next iteration?
As always, your comments are appreciated.
In the next issue, I'll describe how you can run with a repeatable process
and incorporate a Goal-centric approach to Project Management.
Server Response from: ETNASC01