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?