Theory is fine but…

MGT 598 has been the only course that demanded an active interaction with the real world. We learned about various components of
project management – some more technical and scientific (e.g. resource smoothing, project cost allocation, Gantt charts, etc.) and some highlighted as more of an art (e.g. providing leadership, motivating team members, etc).

Based on my prior experience with project management and the learning imparted in the classroom there are a few points that I believe deserve special mention:

  1. A project plan is exactly what it is – a plan. It is a specific course of action for a given combination of expected 0externalities. There are numerous factors influencing the final outcome and to remain relevant, the plan needs to be dynamic. It needs to be tweaked throughout the project to remain consistent with what the team is doing and where they are headed. It is a time-consuming exercise and more-often-than-not what starts out as a sincere effort in management slowly morphs into a series of rule-of-thumb activities. It requires perseverance and patience to ensure all documents are updated. How often does the last iteration of the project plan or risk management document reflect the real status of the project?
  2. I view resource allocation to be a bit more complicated. To start with, we need to have access to the resources before they can be allocated. In real life, everyone is not suitably skilled for all activities. For example, in a construction project, the person operating the roller does not have knowledge of masonry. Similarly, the design team is different from the construction team. We are faced with a similar situation in software development also. The team analyzing user requirements is different from the group of programmers and the project will surely be at risk if you play mix-and-match. So, the resource pool is far from a homogeneous mix where everyone can potentially contribute at every stage. Here is the additional twist – will all resources be available to the project when required.

3. It is mathematically possible to reduce the duration of a task in half by engaging double the required resources, my  experience is slightly different. In the realm of software development, additional people working on an activity usually results in a greater need for coordination, communication and integration. To that extent, instead of reducing elapsed time, it has an effect of increasing activity time. Perhaps it is a similar case with other professions.

4. When preparing project plans a few managers have a tendency to try and be aggressive on timelines and time estimates. There is

also another camp that starts with an ambitious plan and then builds in slack to create a more realistic picture. My focus is on the former group because I think they generate more harm than good for the team. Constantly missing deadlines is demoralizing for the team and soon excessive backlog results in a very uncomfortable situation with senior management. What has been your experience
in such circumstances?


5 thoughts on “Theory is fine but…

  1. I agree with Mayukh, theory is one thing but actually implementing theory is quite another. In the project we had, the plan was something we thought out with great care and detail. However, once the project began, it seemed like the plan was barely even there. It was just a rough guideline amongst an ocean of events that kept changing as we progressed further along the project. Resource allocation is also something that needs to be monitored. Resources are scarce and finite. We don’t have an unlimited supply, using them in the best possible way that we can is extremely important. The thing with resources I believe is that they can make or break a project. Utilizing them properly can not be given enough importance. Reducing the duration of the task stems from being efficient. Efficiency is the greatest indicator of time saving there is. Doing more for less, there are numerous mathematical models as highlighted by the post, but without proper implementation they are all but useless. For what I remember during my projects, the managers always seemed to be chasing after project completion without understanding what is actually required. I have seen projects out right fail because the project manager was slave driving the team rather than taking their input into consideration. That input could have been vital for the project saving not only time but even money.

  2. In my experience, project planning (the act of defining what is to be done) is sometimes the easiest part of the entire process. But when it comes to the execution of the plan, while dealing with the shortcomings and pitfalls, things start to fall apart. As is mentioned in the original post, resources are limited and timelines are tight; it is how these items are overcome that determine the eventually success of the project. Far too often people view project management as the act of creating a process flow and mapping out resources. It is imperative that everyone on the team understands that creating a plan in MS Project is just the beginning. The “real” work begins after that.

  3. Project plans do need to be dynamic to be effective. They represent the steps you believe are necessary to achieve your goal at the time the plan is created, but cannot account for the unknown. For that reason, it would seem wise to build check points into your plan to facilitate making necessary adjustments along the way. Taking into account the skill set of available resources when building the plan also seems important; few projects have interchangeable parts. Doubling resources seems unnecessary. While you should have contingencies built into your project plan, doubling resources seems like a waste. To be effective, plans should have realistic timelines versus aggressive timelines or those with built in slack.

  4. Your writing made me form an opinion about the DePaul MBA program. Whereas it is true that the MGT598 course is the first course that forces direct interaction with the world in the present state, the DePaul MBA program is one of many courses that, “demanded an active interaction with the real world.” There have been numerous numbers of courses, ECO509, MGT502, MGT501 that forced and encouraged direct interaction with the world around us. These courses challenged us to see the world and interpret our projects for Business Conditions, Operations Management and Supply Chain Management based on resource management, project scheduling and personnel behavior for motivation and ethical decision making. Whereas I disagree with your statements about the DePaul MBA Program, I agree with your statement about planning and resource allocation. It is as Roosevelt said, “Plans are worthless, but planning is priceless.” Simply the act of planning and organizing your thoughts will lead to fruit actions and results. If you start there and use that as a spring board for resource allocation, effectively planning your resources for optimal delivery of project outputs, then the issue with resource allocation will not be an issue.

  5. Real world project management that reduces process time in IT projects is more art than science. In Alignment with bullet number 3. There are times when added resources can benefit the timeline, but there are times when a holistic change to the process is required. Using math to reduce the number of activities and time may not be the best way to reduce project time in all instances. How do you build the muscle to understand the difference? It all boils down to experience. While the tools can help to define the baselines, a mature decision is needed on the basis of prior projects to ensure that a time differential can be achieved either through additional resources or by process. Today was one of those days where this was really highlighted. We had a new process being added to an existing system that has never been tried before. We are still uncertain if more resources or a better process will aid in hitting the timeline needed by the customer. At this stage only time Will tell.

Leave a Reply

Your email address will not be published. Required fields are marked *