Project Management “Secrets”


I found this article to be on point with what we discussed during on first Saturday class and will be key to keep in mind for our field project. The article suggests nine “secrets” to project management success. “Secrets” is in quotes, as I don’t believe they are secrets per say, but more guidelines to flow when undertaking a project.


Many of these guidelines are what the class came up with when the professor asked, “What are factors of the successful project teams?” For example, they mention having the full details of the project before starting, having the correct team (and size) in place, being clear on roles and responsibilities, and having goals set. While the article refers to IT projects, the guidelines can be useful to many different types of projects.


I found a few extra pieces of knowledge woven into this article that I had not strongly considered before. First, is to have milestone goals along the project. In my career, I have worked with such short time frame projects, usually two months to four months, that we do not have milestones. Not only is it important to have milestone throughout the project, but to reward employees when the milestones are reached. The reward and appreciation should be sincere and motivational.


I know one of the categories I have to personally work on is micromanaging. Currently, I am leading a project for my work team and I find that my natural instinct is to tell the team now how to do their job. The article points out that team members should feel empowered to do their work without the project manager micromanaging. It will be key for me to have regular touch bases with my team members without overwhelming them.


Additionally, as we all know too well, e-mails on a project can be vast you have the treads of dialogue. Scrolling through e-mails is a time waster and can hinder progress. The article suggests using a digital project management application to keep track of all the important information. These applications can create tasks lists, serve as a virtual filling cabinet, and foster a discussion board.


Already with our group project we have had a ton of e-mails that gets stuck in treads. It is important to keep e-mail subject headers on point to what is contained in the e-mail. We have also started putting key information into a shared Google document in order to find easily.


Lastly, another pitfall that I tend to fall into is not leaving enough time in the project timeline for changes. Often management wants to tweak a portion of the project and if you do not have time built in for changes you may fall behind.


Are there any other guidelines the class would add to the nine in the list the article points out?

Can You Keep Up?

When faced with a project there are many ways to get it done. Here we have two types of strategies to approaching projects: agile and waterfall. Agile is quick paced and is likely to have more short-term goals that “keeps the teams at a constant high pace and productivity” ( Agile projects are not necessarily all short term but the iterations within the project are completed in short periods of time.
The article goes on to explain one of the principles of agile project management, which is time boxing. It “establishes cadence and, after two or three iterations, the team learns how much output they can produce.” Time boxing is not as flexible as other project management techniques. There is a set time frame for each aspect of the project and “it doesn’t matter if you can’t do them to perfection. Completing the task is the goal” (
We can also use cadence in waterfall projects as well. Waterfall is a more traditional approach. Some may say that it’s not as effective as other approaches or to avoid this technique, and others find it is efficient. It follows a stricter schedule, and includes very important details; even the smallest detail is an important one.
Using cadence for waterfall projects can help move the team to being as high energy as the teams in the agile projects. The first point of cadence is keeping a weekly schedule with milestones being completed. The first week should be the week that everyone gathers his or her information. When they meet again at the end of the week the project manager adjusts the schedule to fit the conditions of the information. Which brings us to the second point of cadence: “is the next milestone still on track?” ( The PM adjusts the schedule at the meeting and they settle the next steps there so that the team knows what is happening. To me this seems kind of similar to crashing. The team and project manager adjust the schedule if need be on a weekly basis whereas crashing would most often occur as one point and would adjust each critical path to crash it down to the desired time frame.
The author of the article also provides some suggests as to planning milestones. One of which was timing between milestones should not be too far apart not too close together. I feel that with everything we learned in class, timing is the most flexible yet most critical part of managing the project. You can crash a project down from 14 weeks down to 10 weeks and if you don’t do it right you may be incurring more cost than you should be. If something doesn’t go as planned then you need to be sure you allowed yourself that extra time to adjust anything you need.

So now I turn it over to you:

How do you like to approach projects?
Do you have another strategy to approaching projects?