This is the first set of answers for the same three questions I asked several project management experts. These are thoughts of Shawn Futterer who is a director and the main person standing behind the ICPM (International Community for Project Managers) site which is a great place for all of you who look for high-quality PM content and resources.
There are three situations. For each the question is the same – what would be your project management approach?
You work in a big company and are put in charge of big complex project which is about to be started. People in the company are familiar with Prince-2 but time or budget overruns aren’t anything new, although they’re kept at industry average level. A project team is gathered from different teams – they haven’t worked with each other on any project yet.
I would have to say that in the given circumstance, I would use the following tactics:
1. For Team building, I would host a function outside of the workplace to allow the team members to get to know one another on a personal level. This should lend itself to improving team performance, boost morale and generally keep spirits high.
2. For Team Work I would hold more frequent team meetings. Whether in person or virtual the coming together of team members to discuss status, challenges, roadblocks and successes is crucial in creating a cohesive team environment. If the company standard was 1 meeting per week, I would hold 2 until such time as I felt the team was functioning like a well oiled machine.
3. For Schedule overruns, I would first define the critical path and then employ some techniques such as schedule crashing or fast tracking, running any tasks in a concurrent fashion that can be. These are basic PM techniques. A more advanced approach could be something such as this personal practice of mine; when working with consultants, vendors and outsourced partners I like to define contract terms based on performance. Rewards for exceeding goals and penalties for missing deadlines. This assumes the PM has the ability to source and select vendors. This is fine and good to motivate the vendor to exceed goals and meet deadlines, but it does not help a project that’s behind schedule get back on track. For that we need to start with the basics, Crash and Fast Track. In extreme circumstance we might need to reallocate or swap resources from non-critical tasks to those that are behind schedule. We might need to simply work overtime. This may cause us to go over budget though, so we need to be wary of this. We should absolutely review all upcoming tasks for Float and cut where we can.
4. For budget overruns, I would determine if the budgetary overrun is a result of scope creep. In my experience this is often the case. If scope creep is an issue, we need to institute tighter change control policies. This can dramatically impact our project and keep costs down. Next I might look at things like: material costs and determine if they can be reduced. Are we working overtime? If so, can it be cut down? Do I have salaried employees that can put in extra hours in exchange for time off later? Lastly, a best practice is to calculate a budget contingency when you’re first assigned to a project. Every good PM knows he/she should expect the unexpected. It’s never a bad idea to try and negotiate for a contingency fund for just such cases.
5. In the end if we finish over budget or behind schedule, internal processes need to be reviewed. This, again in my experience, is often a cause for concern. Which process can be improved to have a positive impact on our approach to Project Management in general?
You’re hired to clean up the mess in projects in company of 70 people. So far the company struggles to do any project on time or without major problems. Project management is pretty non-existent and software development along with quality assurance is drowned in chaos.
In this circumstance I might employ the following:
1. A company of 70 people does not require a long drawn out methodology for PM. In this smaller company environment, a projectized approach to PM is desirable, in my opinion. We would use a simple 1- or 2-page methodology to address the basics such as project charter, funding approval, quality control and change control and close out. First thing a small company needs to do is determine whether or not they should take on a new project. Some simple ROI and earned value calculations should be performed. Once a project is accepted, the PM is responsible for it in its entirety. Now we are able to institute some basic PM best practices including milestone definition, task management, team selection and resource allocation and performance management.
2. As with any project, some tasks can be run concurrently, while others have start-stop dependencies. When working with software it’s crucial to define task start-stops and hand-offs to downstream programmers.
3. Scope Management is also crucial. Small companies can be more susceptible to scope creep raising from a desire to satisfy their consumer or marketplace. Change control policies need to be defined and tightly tied to the funding approval and scheduling processes. Change scope only if it makes sense. Importantly, make sure the project sponsors approve scope changes. All other items should be addressed as a separate project in a later phase.
You organize a startup of four people, including yourself. The idea you work on however puts pretty strict requirements when it comes to software performance, high availability and quality. The team isn’t going to grow for some time but in a perspective of year you hope to see a dozen people on board.
This is project management 101, in my opinion. I’m not stranger to a start-up with limited resources, a fast paced schedule to get to market, high quality aspirations, tight budget constraints and the list goes on and on… In this scenario, it’s important to create work packages, distribute responsibilities and work load balance. By taking time upfront to define common practices, the start-up saves time and money down the road. Answering questions like “How will we do things?” “Why we will do them that way?” and “What benefits does this method create?” are a good way to start to define yourself in a startup. Create your methodology as a pathway to success. <
There is a degree of value in researching and thinking about your business in a systematic way. Planning helps you to think things through thoroughly. Learn to be critical of your own ideas, this should help ensure those that you implement are sound. Collectively as a group we should determine our PM approach. As it relates to software, do we use SCRUM, Agile, Xtreme programming, or something else? We need to define the iterative process and then incorporate that into our methodology.
In this scenario, there are four people in the start up and there will undoubtedly be more than 1 project going on at any given time. I’ve had a degree of success in having each partner act as a traditional Project Manager where each is assigned to lead a project or a phase of a project. This helps with my points above about responsibilities and workload balancing.
These are answers from Shawn. Soon there will be other opinions on the same problems.
I encourage you to keep an eye on whole what would be your PM approach series.