July 2010 PM Survey – The Project Schedule
Posted by Brad Egeland
It’s hard to believe it’s July already, but a new month means it’s time for a new survey. This month, I’d like to get a feel for what we use for project scheduling and how we use it.
The survey is available now through late July at this address:
www.bradegeland.com/july-2010-survey.html
So, for question #1 – I want to know what tool you’re using. There are a lot of tools out there so I’m just looking for the name. You don’t have to tell me if it’s web-based or not – I think we’ll get into more of that in the next month or so.
Questions #2 & #3 – let the readers know how close to the vest you keep the project schedule. Does just the project manager revise and distribute the schedule? Is it a collaborative effort with the project team – do you let others go in and revise task status on percent completes and effort estimates? And do you let the customer do anything but look at it? Are there ever any projects where you allow update capability for the customer? I’m assuming this is probably almost never, but who knows.
Question #4 – Do you use the project schedule to actually track project costs? Are the hourly rates of the project resources and costs for materials entered into the project schedule or do you track project costs through a different mechanism?
Upfront Project Management Involvement
Posted by Brad Egeland
I recently had the pleasant opportunity of having a discussion with several members of an organization who seem to be ‘getting it.’ And by getting it, they seem to understand that Sales has their definite purpose, but before everything is locked in place on an engagement, that Sales team really needs involvement from the delivery team to make sure this is all going to work. Sounds logical, right? Well, many organizations are making it a lot harder than it should be. I apologize if this sounds old to you since I’ve written about it before…but I hope you’ll stick with me and read on…
Sales is great, but….
Sales is obviously a key organization in any professional services company. Without sales, we’d have no projects to work on. However, many companies that I’ve worked with or for seem to think that there is a distinct line between Sales and the delivery part of the organization. You often hear, “Here, Sales closed this deal and now it’s your project – link up with Sales and get the handoff information so you can start the project.” Those words make me cringe. There are probably a long list of things that are wrong with that process, but I can give you three major ones right now:
#1 – Sales is primarily concerned with the sale
Sales is worried about making sales. After all, it is their job. And their salaries, commissions, and bonuses depend on it. If they didn’t make the sales, the rest of us in the professional services organization would have nothing to deliver on.
What’s wrong with this? Nothing really – but as I’ll discuss in #2 below, they aren’t Delivery and therefore are not in tune with what Delivery needs out of the Sales process.
The Complexity of Virtual Teams
Posted by Brad Egeland
I’ve made no secret of my promotion of remote project management and virtual teams running project engagements. There are definite upsides to the remote project manager and the virtual team situation. When project resources are dispersed – as they often are these days – running the project remotely definitely promotes many green project management practices. It also allows for quick project action and decision-making, and can greatly reduce the cost of the overall project.
That said, running a project virtually is not without its own complexities. I’d like to dig a little deeper into these here for this article.
It is easy to characterize the types of virtual teams using the same categories as traditional teams. They can, however, be much more complex. The two primary categories of variables that make virtual teams more complex are: (1) they cross boundaries related to time, distance (geography), and organization; and (2) they communicate (share information) and collaborate (work together to produce a product) using technology.
As the distance between team members increases, so do differences in time zones. This can sometimes make communicating and collaborating at the same time problematic. Working across national boundaries complicates the situation because differences in language, culture, and access to technology impede effective communication and collaboration.
Making Good Project Decisions
Posted by Brad Egeland
Decision-making is an ongoing task on every project engagement. Key decisions have to be made throughout by everyone including the project manager, the project team members, the customer, executive management, and usually other stakeholders. They may be as simple as when to hold a meeting or as difficult as making a go- no-go decision on a phase of the project or the entire project.
What we often lack when making some key decisions is the right information at the right time. We all know that making what seems to be the right decision based on information that ends up being inaccurate or out of date can be fatal to the project.
What if you could only make decisions on when to cross the street based on a snapshot taken five minutes ago? Would this help? Would you have any confidence in whether or not you should cross the street? After all, it could be a life or death decision.
Well, that’s often how organizations are continually making business and technology decisions. Many decisions we make on projects are based on what we knew two days ago or two weeks ago or what someone told us last Thursday. Ideally, information would be flowing to all key personnel constantly and we would be making key business, project, and technology decisions based on what we just learned – not what we knew last week. What if you could make sense of what you learn as fast as you learn it and put that into play?
There is no magic wand to wave to make this all happen. However, since the project manager is the key focal point for all communication on the project, there are some things – or at least some actions – that can be put into place that will help ensure that the right information is getting to the right people as quickly as possible. And that, in turn, should help ensure that the project decisions that are made are based on the most relevant and accurate information possible.
These are:
Develop and distribute a communication plan
The key to getting all of this communication off on the right foot is to publish a communication plan for the project at the outset. Produce this document shortly after kickoff and let it document and set the tone for all communication that will flow on the project. This document will correctly set expectations of how, when, where and through who communication will happen. For more information on the project communication plan, please read an earlier article of mine on the topic here. You can also download a copy of one of my actual project communication plans to use as a template. Go to www.bradegeland.com and navigate to the Templates & Downloads page to access the sample plan.
When Planning isn’t Enough
Posted by Brad Egeland
You’ve heard the sayings …. “planning is everything” …. “poor planning leads to 80% of all failures”, “plan now, save later”, etc.
So to avoid the failures, enjoy the successes, and reap the career benefits of successful projects you vow to always include enough up front planning in your projects. You won’t budge on that issue. And if the customer hasn’t planned enough heading into the engagement, then you try your hardest to put the brakes on and give them time to do that necessary planning before risking getting the project off on the wrong foot.
So with all this appropriate effort going into up front planning on your projects, what if even that isn’t enough? We know many studies show that 50-75% of all projects fail to some degree or another. It’s not likely that they all fail only due to poor planning. In fact we know that is not the case. So what happens when good planning just isn’t enough? What else can you do to save your projects? What else could you have done to help ensure project success?
From my experience, it’s very difficult to recover from a poorly planned or kicked off project. I’d like to think that none of my projects have been poorly planned, but I can say for certain that I have taken over projects that were not well planned out and were in trouble when I came on board. There are three actions you can attempt to take – likely best taken in the order I’ve set out below – to try to increase your overall chances of still achieving a successful project outcome…
#1 – Work stoppage to re-plan
I personally believe in – and find the most success with – putting a work stoppage or major slowdown in place on a project that I’ve taken over is one of the quickest ways to assess the situation and inject some additional much needed planning. Of course, this additional planning would have been better served and cheaper had it happened at the beginning of the project. Undoubtedly, there is going to be some hit to the project budget and probably and even greater hit to the project schedule, but it’s far better to do this now than risk losing the project entirely.
