Archive for May, 2013

5 steps to determining project detail

May 14th, 2013    Posted in Popular Questions
 

Once, I was asked by a prospective customer asked me what I charge to build a project schedule. Before I could answer, however, this prospective customer suggested that he would pay me per activity in the project schedule. “Wow,” I thought, “That schedule will be 10,000 activities at $10 an activity. Duh!”

I’ve been thinking about that conversation lately and I remembered my (wrong) answer. Because every project is different, you can’t build your rates like that, because it would not be consistent across various projects. There are many factors that go into project size. The number of project tasks certainly plays an important role in determining a project schedule’s cost, but it’s more complex than simply counting the number of activities it contains.

Here are the five questions I ask to drill down project schedule needs:

  1. First: Is the level of detail dictated by the breakdown (work breakdown structure). If the project requires a great number of breakdowns, then the project schedule will be very detailed. If a project does not have a large scope, then it is safe to assume that it will require fewer tasks. For example: Projects for government work, nuclear work, and outages have more depth and needs than a project for a simple apartment building. The more detailed the work breakdown, the more detailed the schedule.
  2. The second (and often overlooked) question: How often the schedule will be statused. If the project schedule is going to be statused weekly or monthly, then it will not need as much detail. However, if the schedule is statused daily, then it requires a greater level of granularity.
  3. The third question is: “What does management require?” It is important to know exactly what they require at the beginning of the scheduling process. If management’s needs are simple, you can create a less detailed plan. In many cases, project managers speculate on management’s requirements. This will save much time and frustration, if this issue is resolved immediately. There is absolutely no dishonor in asking. Although my old boss disagrees with me on this, and thinks it shows weakness, I believe it shows leadership.
  4. Fourth: Is it a realistic expectation for the project manager to maintain a schedule with a very detailed breakdown? If not, then you should re-examine the level of detail. After all, the schedule does need maintenance. And if the schedule requires more work than the project itself, then it’s missed its aim. An example: My friend Gary built a 4,800-activity schedule. I suggested he modify about 1,000 activities, and cautioned him against having that many activities in his schedule, because he wouldn’t be able to update it. He disagreed at first, but then called 6 weeks later, going back to my original recommendation.
  5. Finally, what method of statusing do you have in place? If team members electronically update the schedule, then it’s more manageable and accurate. If the project manager is required to do all the statusing alone, this becomes too much of a burden. Some projects have a team member whose sole responsiblibility is just collecting statuses. This makes it much easier for the project manager, and allows for a greater level of schedule detail.

What questions do you ask to determine project detail?

No Comments

Project Scheduling: Theory Matters

May 7th, 2013    Posted in Project Rules
 

Having a solid grasp on theory is a crucial prerequisite to building successful project schedules.

A real-world example

Alexis, my wife, is an awesome musician. She has won several music competitions, is the official organist for the Gary South Shore Railcats, and played at halftime for the RKO-produced 1988 SuperBowl. She is also an experienced music teacher, and when she conducts lessons, she uses the “classical” method of teaching. The classical method includes teaching young children how to read music, theory, mechanics of piano, scales, and the like.

It is how music has been taught for centuries. Her emphasis on the classical method, and the importance of theory, is her key to success. At first, this challenges the young students, who initially sound awful. There is so much for the student to learn. The violin students in particular sound like they are gutting a cat at first. Arrgghh! Progress seems to take forever, but eventually they improve. For this, eardrums everywhere are grateful.

Many of her students eventually win music awards, earn “first chair” in the high school band or orchestra, participate in a play, or compete in a local talent show. At the same age her students started music lessons using the classical method, many of their friends were taught the Suzuki method by other instructors. The Suzuki method does not start out with theory lessons—instead, students listen to a tape and relate the music to numbers and colors. Although these children sound much better at an early age, they often drop out before they ever learn music theory. The Suzuki method doesn’t stress theory until much later in the learning process. Ultimately, these students who were taught using the Suzuki method struggle or quit, because they did not initially learn the theory behind the instrument.

So, theory’s a pretty big deal.

Theory comes heavily into play when building a project schedule. Typically, a project schedule’s discussion centers on adding activities and building a bar chart. Creating the bar chart is the easy part once you’re finished gathering information. Anyone can build a bar chart without much study of theory. However learning the theory behind project scheduling is important to completely and fully understand your project’s schedule. Understanding how schedule dates are generated is the key to understanding float. Understanding float is the key to properly manage a schedule. Once you start communicating the schedule and giving project team participants solid information, they have a basis upon which make decisions.

Where do you find theory to be important in project management?

No Comments