Project Management: Duration, Scheduling, Resourcing

Before the project starts, a schedule is created. A schedule determines the macro view of the project, which is then broken down into smaller pieces of work. The person responsible to handle this dynamic is called Scheduler.
The scheduler with all these pieces then creates a work breakdown structure, aka. WBS, which is the wallet for the effort estimated for each task. Then we find the people, then allocate them and then we get moving.
This is not news, we've been doing this for centuries. Just look at the engineering projects. We've been building cathedrals, cities, bridges, castles for many years. We do have a huge experience and materials when the subject comes to manage engineering projects.
With so much experience and materials to build upon, we still find ourselves having an incredible hard time trying to answer one question : how many tasks should we have in a schedule and how long each task should be?

The Art of Estimation
Often we see project schedules that are just plain convoluted and project managers frustrated to isolate the issue with the tasks in the project schedule because they far too macro. Some projects lasts decades, like the construction of the LHCI; some projects are just a few days. But regardless of the length, how to handle a schedule with hundreds, thousands of items?
Different industries, require different project management strategies, that's one of the primary challenges of the project: Delivering on time, on budget. Let's have a look at an IT project. Here a few samples on how to approach the scheduling and task decision process:
IT projects: IT is a very new category of projects; unlike engineering projects the experience is being built fairly recently, which might explain why so many IT projects fail in comparison with older industries.

• Phases: IT projects normally follow a very successful model, which is a design phase, a development/build phase, a quality assurance/testing phase, a documentation phase, and a deployment/release
• Duration: The projects are measured in weeks or months; which makes the task to allocate work a bit easier: days or weeks.
• Resourcing: Resource allocation comes down to a person/unit. If you drink the Agile-koolaid you should try to think about the resources and tasks using  short sprints. Maximum 2 weeks sprints.

Engineering/Construction Projects: This is what the humankind knows how to do it best. Big scale projects.

• Phases: Just like regular planned projects but having an engineering phase at the beginning. This is a very peculiar group, because despite our vast historic experience, this moment always covers one or many aspects that has never been done/thought/designed before.
• Duration:  Engineering projects are visualized in months, years...lasting at minimum weeks and at maximum months.
• Resourcing: Expect to see thousands of tasks in this type of project. So the Scheduler here will have to manage the units person/skill level, rather than person/day. These allocations can become quite complex and often there is a needed to create smaller projects and group them into a program to ease the management and delivery aspect.

Which these concepts in mind we will discuss now how long should be a project.
Divide to Conquer
Let’s imagine an engineering plant location move project. The company bought new offices in another location and needs to phase-out the old offices while transitioning to the new one. First we need to identify the macro-objective, then after that experience show us that the breakdown in smaller pieces are a good approach. Not only because they are more visible to manage and to handle but also because their deliverables can potentially be closed down independent of each other.

you determine the star and finish of the project. then you breakdown in smaller tasks (A, B, C, D, for example), then you try to group these tasks in logical phases (1, 2 and 3, in our case) and for each phase you try to break them in smaller micro tasks. How many micro tasks is up to the manager or responsible for the delivery but in my experience I try to avoid creating less than 5 tasks and more than 15. This is not a rule of guide, it is just the number I personally feel confortable and that has brought me most successes.
Additionally, every time a decision needs to be applied to a task try to get into the habit of asking yourself: can this task be broken down into smaller tasks? Is this going to impact the scope? the main reason for that is because generally some tasks look very simple in the schedule but effectively can become quite complex during the execution…for many reasons. You can’t foresee which ones will be but you can forecast their likelihood of happen.
And yet…
bear in mind that despite all our previous successes and our amazing management skills… some projects will fail, and sometimes nothing can stop that happening. For these cases the same old adage still applies: visibility, visibility, visibility. Make a deliverable visible as much as you can, use whatever powers you have to propagate this visibility. You cannot stop a project from failing, but you can fail gracefully (to use a term from IT management). As long as everyone is aware of how the project is going and we are doing the best we can of the situation everyone is accountable.
The plan is not important, but planning is important.

By Edge Pereira