One of the key parts of running a project is the assignment and management of resource workloads. When we schedule and manage our resources efficiently it gives us the knowledge of when each resource is working and how much they are working at any point within the project. In a previous blog post we have discussed how to easily apply custom contours to resource workloads by using Spot Allocations. FastTrack Schedule 10 also allows users to assign pre-defined Work Contours to resources in order to control when and how each resource will work on activities.
FastTrack Schedule 10 offers a total of 8 pre-defined Work Contour Types. Users can view and modify the contour assigned in either the Schedule View or the Resource View by double-clicking on the activity bar that needs to be modified. Doing this will open the Information Dialogue where the Assignments tab can be selected to see which resources are assigned. In this dialogue we can also control what contour type the resources will use.
First off, let me state that I really, really believe that remote project management is a great solution for most projects. It has worked extremely well for me for the past 10 years or so. But I know it’s not for everyone. Remote project management, while often a sensible and cost-effective approach to managing many standard projects, is definitely not without its challenges. In fact, just in terms of communication, leadership, and relationships it can become very challenging. Add in the rogue developer who is looking to become a one-man team, the business analyst who significant expertise in other technologies but is ‘learning’ a new one while helping lead your implementation, or the documentation specialist who is spread too thin across eight different projects but resides 1,500 miles away from you and you can see how certain logistical issues can really impact your projects if you don’t learn to deal with each one of them methodically and carefully.
Handing off a project that is your baby is not often a very desirable thing to do. You kicked it off, you developed a good relationship with the team and the customer and you are making the decisions and making things happen. But sometimes, there comes that time when you have to hand it off because you’re needed elsewhere – on a project that is a higher priority or that needs your specific experience or expertise. How you go about executing this hand off process can sometimes mean success or failure to the project you’re handing off, and that success or failure can be traced right back to you and how you orchestrated the transition.
Here’s a mistake I make often….referring to the Gantt chart or project schedule as the project plan. And it may be that for a project plan that is all you have or need – especially if you’re running a fairly small project. And we aren’t the only ones making that mistake…it’s a common one. Especially in the world of information technology. In reality, the Gantt chart, or project schedule – is only one component of a real, true project plan.
I’d love to guarantee success to every customer I manage projects for or every client I’ve consulted with. I’d wish I could tell them everything is under control, not to worry, I’ve covered all the bases. Wouldn’t we all? But it’s not possible. Too many things can happen – most are out of our control. By definition, projects are temporary, unique, have goals to meet, multiple tasks to coordinate…sometimes across functional departments and across very diverse organizations, and hopefully have critical impact on a business, organization, industry or customer…depending on the project, of course.
Anything to get the job done, right? On time delivery at any cost (well, any cost except for monetary cost). Well, not exactly. On too many projects, especially ones where meeting the completion date is critical, overtime is the norm rather than the rule. If your projects are anything like mine, you’ve probably found that periodic overtime is fine, but if taken to the extreme, it can have long-term effects on your team members and influence overall performance on the project. Nearly every project has a crunch time. Some project schedule time needs to be caught up, extra effort is needed to push through some issue resolution prior to testing, or the very common ‘all hands on deck’ project deployment scenario comes into play.
In 
Just who exactly is the project sponsor on our projects? The definition of the project sponsor is a senior executive in a corporation (often at or just below board level) who is responsible to the business for the success of the project. So while the project sponsor is senior and may be a figurehead on some projects… on others, they will play a key interactive role and participate daily in the activities of the project.
This could be a long list…especially considering the never ending lists of known and unknown responsibilities for the project manager on every new project. It seems to be ever changing…yet we must be ready. But I’ll keep the list to four for now and welcome your responses, thoughts and additions.