Project Management Tips || Project Management, Collaboration and Knowledge Management Blog

Avoiding the Missed Deadline Problem – Part 2

Brad Egeland — Tue, 15 May 2012 19:56:18 +0000

In Part 1 of this two-part series, we began to look at missed project deadlines and the affects they can have on the project and more importantly, the customer’s perception of how well you and your team are performing on the project. Missed deadlines can very quickly start to affect the customer’s satisfaction with your team’s performance as well as your ability to deliver a final, usable solution in a timely manner. We discussed how unreasonable deadlines can come about. In this final segment, well consider three more potential causes of missed project deadlines.

The need for more resources

Usually throwing more resources at the problem isn’t the correct action to take. What it can do to your project budget is scary. But there are those rare cases where a project actually does need more resources than are currently being applied. Analyze the situation thoroughly and ensure that this is actually the case for your project before onboarding more help, because the next step will be to fight the battle of getting more funding from either the customer or your own organization – and usually both paths will offer considerable resistance.

Resources how are overloaded

Check with your resources – are they overloaded in areas outside of their responsibilities to your project? Are they getting direction from a supervisor to prioritize their work elsewhere. If that’s the case you have two issues: 1) communication problems because they didn’t let you know this and 2) negotiation needs to happen with the other PMs or the supervisor that is creating the priority conflicts. Either way, you must quickly get them focused on your project tasks or replace them. Once again, consider the budget issues related to the corrective action that has to happen here – the project budget may take a hit for a while as either priorities get re-adjusted or the resource is replaced on the project.

The need for different skill sets

Perhaps the resources assigned to the project are lacking some key skills. Meet with the resources that are responsible for the slipping tasks and see where they stand on this. Do they need help? Do you need to bring in a different key resource? You may need to go to their direct supervisor to get the full answer on this but you must take swift action. And if you do end up needing to replace project resources, then the budget will likely take a hit as the new resource gets up to speed. Be sure to make the appropriate adjustments to the budget forecast.

Summary

You can’t always avoid missed deadlines, but watching out for these potential signs may help you to work around them or at least see them coming and try to prepare for them. The key is to be proactive and involve your customer in the decisions and communication along the way. That way, even if you do encounter missed project deadlines – and you probably will to some degree – at least they are aware and are working to help you overcome them…it may help their satisfaction factor in the end.

Related posts brought to you by Yet Another Related Posts Plugin.

Avoiding the Missed Deadline Problem – Part 1

Brad Egeland — Mon, 14 May 2012 18:00:54 +0000

In Part 1 of this two-part series on missed project deadlines we will start to discuss what causes them and how you can react. Ever had a project with no missed deadlines? Seriously now…be honest. It’s the nature of the beast that project deadlines get missed. You can’t build slack time into every task and on some brutal projects you may not have the opportunity to build ANY slack time into ANY tasks. But for the most part, a couple of missed deadlines are not normally a sign of a project in extreme danger. It’s just part of the process – but they can be warning signs. And it is my belief that once you’ve missed a couple of deadlines, you really should be doing everything – and I mean EVERYTHING – in your power to make sure that you miss no more. Otherwise, customer confidence could take a huge hit and you may find yourself sitting in the CEO’s office…or worse…the HR director’s office.

When it’s a chronic problem

What about the projects where missed deadlines are a chronic problem? You know the ones. It’s not just a deadline here and there that is missed. No, it’s a repeating process and you’re constantly scrambling with your team to get tasks back on track, get things completed somewhere close to on time and it seems like you’re repeatedly giving excuses and apologies to the customer and your senior management on missed dates on the project. It’s painful, no doubt about it.

You may have what you believe to be an excellent process for schedule control, and team members are working well together. But in spite of that, you simply don’t meet phase deadlines, and some projects are constantly in danger of being completed way off schedule.

In cases like this, you may be perplexed as to why this is happening, but from the customer standpoint they are feeling more and more uncomfortable with how things are going. Excuses, unknowns, repeatedly missed deadlines….they all lead to significant reductions in customer satisfaction and confidence. If these project troubles are catching you by surprise then that translates to your customer as poor project management. If it appears that you’ve lost control of the project, then your customer will have no confidence in your ability to manage the engagement.

From my experience, when missed task deadlines start to become a real problem on the project, it is often due to one or more of the following reasons. Examing these key possibilities in detail can help get to the root of the problem and get the project team back on track toward on time delivery of critical project tasks.

Unreasonable deadlines

The project schedule was probably drafted by sales or an account manager and then handed of to the project manager. It was then molded into the very detailed schedule that the project is now being managed against and it’s being shared using a tool like Seavus’ Project Viewer. There may have been some unreasonable deadlines that either were overlooked, or were just not changeable. The project manager and team knew they were unreasonable, but the deadline was mandated by something beyond their control – possibly the customer, an industry requirement, or senior management. Sometimes change orders, pressure from above, or misunderstood requirements can leave you with a project schedule that is no longer doable. And if it’s not adjusted, then the project is going to move further and further off track.

That’s all for Part 1. In Part 2, we’ll examine 3 more reasons why project deadlines are often missed and what can be done to work around them.

Related posts brought to you by Yet Another Related Posts Plugin.

When Your Project Client Wants to Hire You – Part 2

Brad Egeland — Wed, 09 May 2012 18:47:00 +0000

In Part 1 of this two-part series on things to consider when you are consulting for a client on a project and that client indicates an interest in hiring you, we looked at the consideration of potentially clashing personalities. This is especially critical for me as I am often consulting for SMBs and working directly with the leadership of the organization – the real entrepreneurial spirit behind the company. I have ideas of my own so I have to be careful to take something like this into consideration and avoid walking into a situation that simply will never turn out well.

Below are two more things that you’ll want to consider if this type of situation comes up for you…

Will the client be ok if I consult on the side?

If you have any clients in your past that have been pleased with you – and if you’re still consulting then you probably do – what happens when they call you back? Will your potential new employer be ok with you consulting on the side? Is it even allowed as part of their company policies?

I went to work as a direct hire for a company that didn’t allow consulting on the side. I still did it, but just a few incidents here and there to keep past clients happy until that time when I was back consulting again (because nothing is forever anymore). It worked for me, but it also could have ended badly. If it comes up, will you just consult, or will you tell your employer? I knew the side consulting wouldn’t interfere and I was working remotely anyway so I just did it, but some consulting situations can end up being an interference with full time work. I was lucky. Just remember, this may be an issue you’ll have to deal with.

Does this client have a real long-term need for me?

Finally, a real important thing to consider is this – does this client have a real long-term need or do they just perceive it to be that way? You’re the expert – analyze their situation to the best of your ability. If you solve what they need you to do, then what? Will there be other work for you? Or could you then quickly be laid off? Then what happens?

You won’t have all the answers to those questions, but you do have the client knowledge and expertise to do an assessment of their need. And it’s ok to ask them – especially if you’re concerned about how you fit into their long-term needs. It’s a discussion that really needs to happen before you can make the right decision for you.

Feedback

What about our readers? Have you been faced with offers from clients and, if so, how do you respond? What factors do you consider? Besides the obvious of pay, what can send an offer over the top for you making a ‘yes’ decision much easier to come by? I look forward to your responses.

Related posts brought to you by Yet Another Related Posts Plugin.

Why are PMOs disbanded?

Elizabeth — Wed, 09 May 2012 05:45:17 +0000

Results from a new research study by ESI International show that company restructuring is the top reason why PMOs are disbanded.

The benchmarking survey, entitled The State of the Project Management Office: On the Road to the Next Generation, investigates the current role of the Project/Programme Management Office (PMO), its development to full-blown maturity and value for the overall business. Based on responses from over 3,000 respondents in more than 17 industries on six continents, the research shows that PMOs are still facing a difficult time justifying their existence. The number of PMOs being reported has dropped by 10% over the last 12 months. On a positive note, 5% of respondents said their companies were planning to implement a PMO in the coming year.

Around 55% of respondents report that the value of their PMO was questioned by key stakeholders – usually senior management – over the last 12 months. That’s an increase of about 15% on the results from 2011. As a result of executive scrutiny and organisational restructuring a number of PMOs have been shut down during the year.

Despite one in three PMOs being managed at the level of the C-suite, it looks like PMOs are still struggling to prove that they add (or can add) value. Even after being in place for years, PMOs are still subject to scrutiny and being are disbanded – one in three of the PMOs which were reported to have closed this year were 5 years old, or older. Maturity is not a safety net for PMOs. It is not just new units that get closed down. However, maturity does not equal contribution to the company’s performance. It could well be that these PMOs have stopped being effective, or were never effective in the first place. Maybe it took the impact of the recession and budget cuts for someone to truly scrutinise what they were delivering.

Reasons for disbanding a PMO

The top reason cited in the survey for disbanding a PMO was restructuring. Perhaps this has something to do with the fact that of the respondents reporting that their company had a PMO, over 60% said there were multiple PMOs in operation. Restructuring could mean consolidating PMOs into a single, corporate unit.

An executive decision or change in management was cited as the reason why one in four PMOs were closed down. This category is not detailed enough to provide relevant information about why these PMOs were disbanded. There are of course executives who approach the organisation chart with a red pen when it comes to making savings. But I’m sure there are far more senior executives who consider many factors when it comes to closing down departments. What is clear with this broad category is that the people completing the survey did not have enough information about why the PMO was disbanded. Perhaps the lesson for executives choosing to shut down PMOs is to ensure that the rationale behind the decision is adequately communicated.

This is also shown by the third category: Don’t Know. Over 10% of PMO closures fell in to this category, with respondents not having any idea why the department was closed. Given that this impacts jobs, project teams, projects and corporate decision making at portfolio level, it would be wise for executives to share information about restructuring or disbandment in a much more transparent way.

While executives may claim that the PMO does not add value and thus should be disbanded, the results show that PMOs were valued by those who used them. Of the people surveyed who reported that their PMO was disbanded, over 90% said it should be reinstated.

Have you lived through the closure of a PMO or are you facing this during 2012? What happened?

Related posts brought to you by Yet Another Related Posts Plugin.

When Your Project Client Wants to Hire You – Part 1

Brad Egeland — Tue, 08 May 2012 22:16:39 +0000

For those of us who are consulting independently as project managers, there are always lots of interesting, conflicting, and possibly career-changing events that can take place on any consulting engagement. We can’t prepare for all of them, but we can learn to share ideas and advice with each other along the way so we are as prepared as possible to deal with these topics as they come up on our projects. For this two-part series, I’d like to consider the following – what do you do when your project client indicates that they would like you to come on board as a full time employee?

It’s always flattering when a client that you’re consulting for expresses a desire to hire you full-time. They may really desire to keep you around forever or it may be a cost-saving measure on their part disguised as a compliment, but it feels good and lets you know that you’re appreciated, even if they may just be trying to save some money.

Most consultants are probably going to shrug off a hiring offer quickly – especially if their plate is full with clients and there’s no struggle involved in bringing in new clients or making ends meet every month. However, an offer from a client may be enticing if you’re struggling in this economy or if you’re tired of the grind of marketing yourself and always working to increase your client base. That act of always being ‘on’ to sell yourself or always looking for ways to present your skills to a prospective client may be wearing heavily on you and you are thinking of just getting out of it. That’s the consultant who really needs to analyze an offer like this and consider the big picture and the overall effects and changes before hastily jump at the offer or refusing it.

When faced with an offer and a decision like this, the consultant needs to consider several things that the regular employee doesn’t usually have to take ito consideration. The current employee or direct hire candidate just has to look at the location, company, hours, and pay and decide yes or no, in most cases. For the consultant, all those things are also part of the decision, but their list of factors is longer. Let’s consider a few…

Will our personalities clash?

One of the first things you need to consider is…can you ‘work for the man?’ Ok, I hate that term, but if you’re a consultant, you know what I mean. Can you work for a manager, supervisor, or ‘boss’ who may drive you crazy? Can you work for one who may try to micro-manage you? You’re used to being your own boss. When you work for a client, yes, they’re kind of like your manager…in a very indirect way. But they treat you like the expert you are and usually don’t question what you’re doing. In the end they’re either happy or they aren’t. But they aren’t trying to manage your every move. They aren’t trying to pin you down daily on your task progress, etc. If you enter into the wrong work situation as an employee, that can happen and how long will you last in that position? It’s a very real issue that you must consider carefully.

In Part 2 of this two-part series, we’ll look at two more considerations as you struggle to decide if you want to give up most or all of your consulting practice and go the safe route (or is it really the safe route?) or should you stay the course and say no…and what will that do to your relationship on the current engagement?

Related posts brought to you by Yet Another Related Posts Plugin.

Developing A Project Management Office

Emilija — Tue, 08 May 2012 07:45:06 +0000

As the financial crisis looms over the horizon for many firms around the globe, business owners have come to the realization that having a robust structure is crucial to a company’s success. This article will describe four steps that will help businesses achieve a centralized infrastructure and an effective project management office.

The importance of project management

Despite its name, project management does not concern itself solely with projects, but also with the complex network of individuals, resources, technology, and communications within a company.

A survey studied 252 companies and discovered that only 32% of their projects were successful, in terms of budget, quality, and their time frame. Failure rates like these highlight the importance of setting up an efficient project management office that seeks to introduce best practices in terms of excellence, achievement, and leadership.

Project management made simple

1- Know your needs and establish definite goals

Any business that needs its organizational culture changed, or that requires an improved prioritization process will benefit from setting up a project management office. However, you need to be specific. Are your priorities scheduling, cost control, communication, or perhaps all of them? What are your business projections for the next five to ten years?

Also, it is important to keep in mind that setting up a PMO will be an investment in terms of time and money. Is your budget able to accommodate this? Can you enlist the support of management on a long-term basis?

2- Selecting the right project management software

This step is closely linked to the previous point. Knowing your organizational needs is primordial in order to choose a software package that will support your business requirements. Many businesses are choosing to implement online project management software instead of the more traditional desktop-based packages. Web-based solutions offer many advantages, such as only needing to install one version, being easily and simultaneously accessible to many employees, and offering a centralized data repository.

Generally speaking, the best online project management software will offer an integral solution to your current and future needs.

3- Implementing the first stage

As with any organizational change, implementing a PMO is best done in several stages. You may start seeing results after the first six months, but full deployment of a PMO usually takes between 3 to 5 years.

During the first stage, you should develop your strategy, build your team, and train staff on basic implementation processes and reporting mechanisms. It is also at this point when standards should be fixed in order to achieve consistency. Additionally, it is necessary to establish metrics, so that benefits and results can be objectively measured.

4- Second stage

The team can now be trained in more complex processes and techniques. It should be possible to start measuring results against pre-determined benchmarks. Also, evaluate the impact of the PMO on the rest of the organization. Is centralization being accepted? Have your organizational needs changed? Is change evident in clients’ feedback? Are your chosen strategies and methodologies yielding results? Evaluate, re-evaluate, and change when necessary.

This is a guest post from James Bentham, writing on behalf of Iris Projectminder. James specialises in business and technology topics and enjoys exploring the relationship between the two.

Related posts brought to you by Yet Another Related Posts Plugin.

The change control process

Elizabeth — Sun, 06 May 2012 19:32:16 +0000

Every project needs change control. If you don’t have a process in place, people will ask for new requirements to be added or old ones taken away, dates to be changed, different functionality included, new teams to get the end products and a whole host of other things that are going to make your life difficult.

That’s not to say that change is bad. Change is good. Normally people change things for perfectly valid, business-sensible reasons. The only reason change control is needed is so that you know exactly what you are working on at any time. It’s also a way to protect your team from the type of person who rocks up to their desk and says, “Can you just…”

Here is a six-step change control process that you can implement straight away on your project.

1. Request for Change is produced

This can be on a standard template, via email, or in the form of a “Can you just…” request. A Request for Change (RFC) can be formal or informal. The point is that you have to have a request submitted in some format.

2. Receive RFC

The RFC will normally go to the project manager. It could, however, be given to any member of the project team. Make sure that your team know what to do with change requests if they are asked to incorporate a change. Changes could also go to the program manager if you are working on a program, as they may have implications for other projects.

Another option is that RFCs go directly to the Project Management Office. The team there are likely to have to delegate the next step to you as they won’t have the detail, but they can act as a management and administrative help filtering the requests especially if your project has a lot of changes.

3. Analyse RFC

You and the team will have to analyse the RFC. Consider the impact on the scope, budget, timescales and resources.

4. Make the decision

You may want to set limits and guidelines around decision making. For example, if the change can be delivered with no change to budget, you may be authorised to make that decision yourself. If the change requires additional budget or resources, your sponsor may have to make the final decision, based on your recommendation.

If you reject the change, tell the person who submitted the RFC. Explain why the change was rejected. This step is often overlooked and it can be a cause of great resentment amongst the stakeholder community. Taking the time to explain why you could not accommodate their change will help them accept the decision. They may still choose to challenge it, or they may resubmit a modified version of their RFC at a later date.

If you reject the change, the process stops here. If you accept the change, move on to step 5.

5. Incorporate the change into the plans

Changes, by their nature, change things! So you will need to update your project plan, schedule in Seavus Project Viewer or whatever tool you use, resource plan, budget and anything else that is impacted as a result of this change. Rebaseline as necessary. Update all your project paperwork as well.

6. Inform the requestor

Finally, you should tell the person who raised the RFC that their change has been approved. This closes the loop and gives them some feedback. You may also choose to tell them about any increase in resources required to deliver their change, so they have the whole picture about how much impact this change has had.

If you need their help delivering the change, this is the time to ask for it!

A change management process can be very simple, and it helps you keep control of what is happening on the project at any one time. Remember, don’t reject changes because they might seem inconvenient. Do what is right for the project in order to deliver the best possible business results.

PMtips.net is proudly supported by Seavus Products.

Related posts brought to you by Yet Another Related Posts Plugin.

Todd Williams on Rescuing Problem Projects

Elizabeth — Tue, 01 May 2012 05:32:05 +0000

Recently I interviewed Todd Williams about his book, Rescue the Problem Project. We met at the PMI Global Congress in Fort Worth, Texas, and had an iced coffee and a chat about his experiences of dealing with failing projects.

I started off by asking him why he decided to write his book. “I’ve been rescuing projects for somewhere around 25 years,” he said, “and I really enjoy writing so I thought I would put something together.” Todd thought about the concept of a book on turning around failing projects for a couple of years before an accident gave him the catalyst to get started.

“I broke my back and that gave me the opportunity to do something,” he said, explaining that staring at the ceiling got boring after a while. “Once I had the whole thing put together I went out to try to get it published and that was an education in its own!”

Rescue the Problem Project is a book filled with stories and examples. Todd explained that with a quarter of century’s worth of experience, he had hundreds of case studies that he could have drawn on. In the end he settled for around 70 of his favourite examples – changing the names to ensure that the innocence (or guilt) of those involved was protected.

“The examples embedded in the book help you get a feel for what it is like to actually rescue a project,” he said. “I think there is a lot of value to be gained in those case studies. It brings some real life to it and it helps people understand what type of stuff goes on.”

I asked Todd about his most challenging rescue, and he explained that after a stint working in Taiwan and Singapore he took a project working in the Middle East. “It was extremely difficult,” he said, “and had many things to bring in to play that I wasn’t expecting.”

The biggest challenge was the culture. “The first thing I had to do was to understand the culture,” he explained. The change in culture between the Pacific Rim and the Middle East was immense. He recognised that he would have to adapt his working style to better integrate with the team and make a success of the work he had been asked to do. As a result, he had a lightbulb moment. The culture changes that he had to deal with were the same for other people on the project team. They were also having to manage a culture with which they were not familiar. Culture was the key to making sure the project could be saved. “That was what was affecting the entire project,” he said. “That was the big key and a huge learning point for myself.”

I also spoke to Todd about tips he had for project managers who themselves face failing projects. What advice did he have for those with their own projects to rescue?

“Listen,” he advised. “Too many people don’t listen. They jump too quickly to conclusions.” Todd thought at first that this was just a trait belonging to U.S. managers, but now, having worked all round the world, he realises that it is something universal. Project managers and project teams dont spend enough time listening to each other.

“Quite often I’ll be sitting in a project meeting and I’ll hear two people talking to one another,” he explained. “They are agreeing with one another.” But when Todd plays back the conversation, summarising what both parties said, only one is in agreement. The other person hasn’t listened – or hasn’t heard – what the first one was saying.

He advises project managers to try to remove themselves from the situation so that they can fully listen to the arguments and agreements during a discussion. This takes the cultural bias out of the situation. That happens when your expectations of what should happen, based on your societal and cultural reading of the situation, are what you hear, instead of what is actually said. You fill in the blanks with your own expectations. Unfortunately, if you do this you will be disappointed when things don’t go your way in the end.

“Too many times you are sitting in a situation and the culture actually makes us know something that we don’t,” he said. “Our biases turn around on us. You want the answer to come a certain way so you take what people say and turn it around.”

Related posts brought to you by Yet Another Related Posts Plugin.

What if Your Clients are Competing?

Brad Egeland — Tue, 01 May 2012 00:32:20 +0000

Let’s consider this scenario. You’ve lined up several clients in one industry. You’ve done a considerable amount of repeat work for some of them – all without question or any concerns on the part of each client. Now, you’re negotiating work with a new client and they see from your website that you have worked with or are currently working with one of their competitors. They express concern. How do you deal with this?

You can’t really say, “Don’t worry.” If they are mentioning it to you, then they are concerned enough for you to care. And if the customer is concerned then you must also be concerned. Never brush off customer concerns easily – it can lead to customer frustrations and concerns with your overall ability to handle the engagement. Your goal – at all times during the engagement – should be to keep customer satisfaction high.

I’ve personally had this come up in two different types of work that I do. It happened to two years ago when I was implementing the same software solution for two different organizations in the airline industry. And it happened to me again two weeks ago concerning my writing of professional articles for two competing software companies. I’ll discuss how I handled both situations…

Example #1

As I mentioned, my first example concerns two competing organizations in the airline industry. I had recently completed a customized software implementation for one airline and I was in the process of preparing myself and my team for a new project kickoff with a competing airline when the issue was raised by the new client.

Since both of these were long term engagements worth tens of thousands of dollars with the potential for future business, it was critical that I handle this concern carefully. There was no way I was going to take it lightly nor was I going to do anything to give my new client the impression that their concern was odd. What I wanted to do – what I knew I must do is convince them politely that their concern was invalid. That there was nothing to worry about.

I sat down with the new client and documented their concerns one by one. There were only 4 or 5 concerns that they had overall – most were related to some of the proprietary ways they do things in the airline industry and how certain calculations are derived (yes, these were very relevant to the software solution I was implementing). In the end, it took two things – signing an NDA (non-disclosure agreement), of course (this is something I actually then later went back and signed with the original client I had previously worked with so that I was covered on both sides) and it also took just getting to know this new client better. Once we discussed this situation, how we were going to customize the product, how I was going to manage the engagement, and how their processes were fairly similar across the industry based on my general knowledge I had acquired, they were much more comfortable with me, the project, and the information we were working with.

Example #2

In my second situation I was writing professional articles for one software organization and had been doing this for several months. I discussed doing the same with a competitor. Understand that the articles were more expert content related to the industry rather than specific content about either vendor’s software offering. The potential new client became concerned that I was also writing directly for one of their competitors and were hesitant to move forward with a working relationship. We discussed the content of the articles, confirmed the understanding that there was no conflict of interest involved due to the content of the material, and established the understanding that recognition of articles with my name associated with them might only serve to help the recognition of their software product even when it appears on another site. Their concerns were soon alleviated and we were able to move forward with a working agreement.

Summary

The bottom line is it sometimes all it takes is a mutual understanding of the situation. You must take the time to sit down with your client and listen to their concerns. That way you can jointly come up with the best way to move forward on the project consulting engagement with them without the client feeling uncomfortable or like their confidentiality is being compromised. Their data, their processes, and the way they do business is important to them. Very important. They stake their jobs and their profitability on it. So act like it’s important. Always offer – or insist – on signing an NDA so they immediately believe you’re protecting their best interests. Never break that confidentiality agreement because the legal, financial, and reputation consequences for you would be huge.

Related posts brought to you by Yet Another Related Posts Plugin.

Staying Focused on the Project Goals – Part 2

Brad Egeland — Mon, 30 Apr 2012 01:00:12 +0000

In Part 1 of this two-part series, we looked at the first two of four ways I usually work to keep my project team members focused on the goals of my project. These two were: engaging them in the requirements process and continually providing them with up-to-date project status info and revised project schedules. Any collaboration tool will do, but Seavus’ Project Viewer is a handy collaboration tool if you are primarily using MS Project for your scheduling and resource management needs.

In this Part 2, we’ll examine my next two suggested steps or actions: making the team responsible for their own status reporting and keeping resource forecasting continually revised so as to retain your project team throughout the engagement.

#3 – Make team members responsible for their own status reporting on the project. As the project manager, it can be a common occurrence for you to end up doing all the talking on the weekly project status calls with the customer. However, if you want your team to be accountable for their tasks and for them to feel like they’re making major contributions and getting recognition for their work, then let them own the status reporting of those tasks assigned to them. Make sure that they are on all of the status calls and let them own the process of giving status updates to the customer. It definitely changes their attitude and preparation for the weekly calls.

#4 – Continually revise the resource forecast throughout. This one is critical because you don’t want to learn it the hard way like I did on one project. If you don’t keep your resource forecasting up to date, you may end up losing a key project resource to another project. Depending on how your organization works, this could be critical.

Many matrix organizations rely on resource forecasts on their projects to ensure that the company IT resources are as close to 100% utilization as possible. If you show that you don’t need your business analyst for a three-week period in October, then management is likely to staff that BA during that time on another project. If things change and you need that BA but you’ve failed to update your resource plan, then you may find yourself without a key resource when you need them on a critical task.

Make sure you forecasting is up-to-date on a weekly basis and make sure that your project team members and their managers have that resource forecast in front of them every week and that they know what your needs are.

Related posts brought to you by Yet Another Related Posts Plugin.