I’ve been surprised to find that there’s still much ambiguity about the difference between the 3P’s of Projectland. Given the complexity out there of different organizations and how no two environments are ever alike, I probably shouldn’t be surprised. I’ve noticed over the years that most companies approach organization by throwing all their work up in the air and drawing circles around groups of whatever lands on the floor with crime scene chalk.
However, to help clear things up, I made the above diagram. Take, use, print, whatever. Because companies all have their own way of doing things, this diagram will never be a one-size-fits-all. But hopefully it’s a reasonable guideline to help give your work some structure.
The TV show model is the easiest for most folks to get their head around. The WB (I believe) was the network to produce my favourite TV show ever. They had to worry about all of their shows, funding, and strategic planning. In addition to their shows, they would have had loose projects that didn’t fit into any particular program.
My favourite show ever (Buffy) had loose time boundaries (it gets cancelled when it gets cancelled), and fairly defined high level scope boundaries. Within their story arcs, they have to worry about choosing strategic plots (development over time, which Joss Whedon is a MASTER at), or tactical plots (whoops we wrote ourselves into a corner OR crap we have a blank spot in the schedule and nothing to fill it with).
And of course each episode can be considered its own project, with very clear time, money and scope boundaries (has to fit within the time slot, has to be ready to air, has to fit within existing and current story arcs, etc.). The specific skills required to produce one episode are clear and the processes required for execution are also clear prior to the onset of execution. (I know, I know, Dark Willow was more than one episode but it was AWESOME)
While not every business makes TV shows, the same organization can still apply. Insurance companies print policies to mail to policyholders. The printing of different kinds of policies could be considered one program. The development of one particular game title could be considered a program (if the game title is large enough, it may even have subprograms before it gets into specific projects).
There’s lots of different ways to cut it within the basic overall structure, but keeping the above attributes and challenges of each group in mind should help give your work a bit of definition.
