Archive for the ‘General Project Management’ Category

Microsoft Project 2010 – Does Your Viewer Support It?

Monday, June 14th, 2010

Are you using Microsoft Project 2010? You will find that other software companies have not yet made their project Viewers compatible. There is good news and hope, however! Our Steelray Project Viewer version 4.0.0.0 works with the newest version of Microsoft Project. We have spent many months getting ready and are happy to announce that we’ve succeeded where no other company has!

Please see http://www.steelray.com/download.php?prod=spv for your ten-day trial version today!

Project Closeout

Tuesday, November 17th, 2009

By Laura Bamberg – Global Sales Administrator

For project managers, one of their favorite processes is closing out their project. This can involve some celebration, especially if the road has been long and laden with pitfalls successfully navigated!

However, at the close of a project, how often do you get to say it was finished on time, on budget, with no scope creep or numerous changes? If I were to poll all of you, I would bet that doesn’t happen often. Instead, it seems that simply closing a project within a few months of its planned closing date constitutes a success. So how can you make the project closeout phase help improve the success of future projects?

STUDY YOUR LESSONS

My first piece of advice is to study this scenario before you get to it, in the form of lessons learned or previous project audits. What happened with a similar project that led to problems with closing on time and budget? What could be done differently? If the same factors that negatively influenced that last project are immutable, what kind of work-around can be constructed?

Let’s say one of the main issues with a previous, similar project was the failure of managing stakeholder expectations, in that the stakeholders wanted something that was impossible to provide, so they ended up taking what they could get, but only after compromising the project schedule. If you’re working with the same stakeholders, chances are they are going to be just as challenging this time around.

Who could go to bat for you?  A trusted member of either your company or someone in the client’s company, to explain the project needs in a way the stakeholders can understand, or at least advise you on how to do it? Did you provide enough information previously, or did you present it in a way that alienated them to some degree? Review what happened and institute better ways of managing stakeholders.

CLOSE PERTINENT DOCUMENTS

Michael D. Taylor wrote a recent blog post about closing contracts that project managers should read if they use the procurements process. I was reminded that some project managers fear contracted work because they fear the legal complexities involved. But I’m also reminded that this is the reason why their lawyers are involved to begin with. A brief meeting to ensure the contract is ready for closure is a good idea.

RELEASE STAFF

Taylor also wrote that a project’s close involves releasing personnel to other tasks. However, if you do so without performance evaluations, you are missing a golden opportunity. Take this chance to re-evaluate who was used for what work. You may find that you made the wrong choice when you see how another team member could have done it better. Remind yourself to monitor performance next time in a case like this. Are you utilizing your team’s talent correctly?

DOCUMENT YOUR LESSONS

Do you document lessons learned? If not, is it because it’s not expected of you because your company, as a general rule, doesn’t value them? Are they completed as rote? If so, take some time at the close of your project to run through it, start to finish, in your mind. Take this responsibility seriously.

It may be frustrating after months of documentation, and you may be ready to pop the champagne cork already, but lessons learned are valuable to you and to your team, as well as your company. If you want to present a better case to those stakeholders, there’s nothing like a black and white reminder of why the project could have ended better!  Future projects will go better when projects are closed effectively.

Engaging the Team: Project Management Kickoff Meetings

Tuesday, November 3rd, 2009

By Laura Bamberg – Global Sales Administrator

How do you use a project management kickoff meeting to ensure your team effectively communicates during your project? Michael Sisco wrote that this is the single best occasion to give common goals to the team and to motivate them.

When I think back to all the meetings I sat through at previous companies, mostly I remember how useless many of them seemed. It made me think about what all those facilitators could have done to better engage us for the duration of the work ahead. A great kickoff meeting is simply a start to making this happen, but it is very important to set the right tone of this meeting and to cover as much of the “big” stuff as quickly but clearly as possible.

The more I learn about project management, the more I realize how important two things are – planning and documentation. Sisco recommends using a clear-cut agenda, and I would advise that you have it distributed before the meeting (but not more than a day or two so that it doesn’t get lost in the shuffle). Let everyone know that if they have something to add it will be addressed at your next meeting.

The length of the meeting depends on the magnitude of the project. Here are some things to keep in mind:

  • If the team is newly put together, doesn’t know each other well, or if there are several new members to an existing team, explain everyone’s roles. If there is a high level of distrust, work on it now before it blows up in your face mid-project.  Also identify stakeholders and brief the team on any necessary information regarding the stakeholders.
  • If this is a new team, or there are several new faces, it’s also a good idea to discuss your change request policies, and if you don’t use a change control board, explain what methods will be used to avoid deviating from these policies down the line.
  • Review significant expectations, and let everyone know there will be time to discuss these in greater depth when the need arises so that you don’t slow down the meeting pace.

A well-run kickoff meeting doesn’t guarantee the ultimate success of a project, of course, but it certainly gives the team a push in the right direction.

Delivering Project Plans to Your Team

Wednesday, October 28th, 2009

By Laura Bamberg – Global Sales Administrator

Recently one of our salespeople was talking to project managers on the trade show floor at a conference and discovered that many of them still print their project plans to pdf documents and distribute to their team and stakeholders.

If you prefer to use a program like Excel, it’s important to note that this is not helpful for delivering project plans over the long term any more than printing to a pdf. What if the team members need to add information to your project plan? This is not at all feasible for them. This reminds us that Steelray Project Viewer saves project managers time and prevents the hassle of trying to print plans to a pdf or strictly using Excel.

It would be simpler and faster to send an e-mail to your team, telling them where the mpp file is located so they can see it. The team can open it with our Microsoft Project viewer, and there will be no problem trying to get it to print correctly to a pdf or making sure everything exports to Excel perfectly. It is almost the same as if you had created it in Microsoft Project.

What are some of the other ways that our Viewer can help?

  • There is no need to update to a third-party server – instead, store it on your server, and there is no need to create a new pdf.
  • A pdf gives you one view – our Viewer gives you a sight-line to overdue tasks, incomplete, and tasks beginning this week, as well as tasks assigned to a person and more.
  • Filter and navigate your view. Drill down to all parts of critical project information.
  • A pdf file limits your zoom levels because you only have two options – bigger or smaller. Our Viewer allows multiple zoom levels with different timescales.
  • The Viewer is also a navigator – it allows you to search in the same way you would use a search engine on the web.
  • A team member can send a status update to the project manager’s email inbox.
  • If you like using Excel and feel comfortable with it, you can use one of our Excel templates that’s included with our Viewer. You can also export tasks to Excel, as well as html.

What holds you back from using a better tool? Could it be that there are many products that cost a great deal of money out there, each vying for your attention and budget? Some companies charge a monthly fee, which actually costs you much more than the cost of our viewer.

We love to hear your feedback, so keep it coming! We’ve enjoyed our conversations with you on Twitter and LinkedIn.

Project Management Metrics

Friday, October 9th, 2009

By Laura Bamberg – Global Sales Administrator

As a measurement tool, metrics vary in complexity, and they are not always a one-size-fits-all solution. One way your company finds success might not work for another.  You should take into account your enterprise environmental factors to begin with, but you can complete a project (of any size and at any company better by incorporating them into your project.

Metrics can be used throughout several phases of your project.  Using metrics can ensure better project quality by helping you move forward faster with greater quality. The more information you can pin down and the more mistakes you can catch before they lead to other mistakes, the easier it is to complete your project on time, on budget, and with improved results compared to past projects. Here are some project components that benefit from the use of metrics:

Organizational Process Assets

In this tome (or database or dusty cabinet) lie answers to project questions you may not have even thought of, in the form of metrics. This is a good place to look before you even gather stakeholder requirements, especially if the information you need to present to stakeholders is still fuzzy – this will help that information coalesce.

Stakeholder Requirements

Lately, I’ve seen several posts on LinkedIn about best practices of gathering stakeholder requirements or what to do if you’re having trouble communicating with your stakeholders. In my last post, I suggested that project managers should be firm with their stakeholders and managing those expectations. Metrics are a very good way to do that – if you can’t give a stakeholder something that can be measured, how can you promise an end result? For example, if you’re building an oven, how can a stakeholder require better cooking performance if you don’t know what this is to begin with?

Project Management Plan

Because the plan contains the blueprint for your project and it’s updated frequently, it’s never too late to add metrics to the plan. For example – let’s say that a material you are now using to build that oven means that it can cook more evenly at lower temperatures.  Measuring this type of performance is an important metric, because it also means that cooking time is shorter than in any other oven your company has built – so you use this on your current project (especially when testing quality and performance), as well as future projects.

For more perspective on this, see a post by Suresh Malladi, PMP regarding ways to improve your projects.

Quality Control

Here is another great area where metrics come in handy. Quality is often about measurements, so using metrics makes perfect sense. Comparing the quality of deliverables in your project to previous project deliverables can provide an excellent source for metrics. This is not always an apples to apples comparison, because every project is different, but it is still an effective tool to help gauge a project’s success.

Project Performance

If you’ve never used metrics as part of your projects, quality control or project performance are two places you’d automatically expect to see them. Adam Thody wrote a piece on using metrics during the project performance evaluation and made the case that “post-project performance reviews” are not the only times you should look at lessons learned. He wrote that unless you set up metrics that people will actually use, you’re destined to fail.

So, why do people dislike using metrics, especially if they’ve not been consistently used on projects or if they change and become a bit more difficult? The short answer is that people don’t always like change! They wonder if it will take more time out of their busy day, if the metrics will actually benefit the project, or just create busy-work.  Once you begin using metrics, you realize that even though they might not all be helpful, you still found measurements that provide overall value for your project.  So, on your next project, you have a better idea of what type of metrics are needed. In order to create metrics your project team will use, you must have insight into what works best for your company, and this requires a bit of planning, but once you put the appropriate metrics into practice, what a difference they can make!

The Confidence Question

Wednesday, September 9th, 2009

Every project plan has an end date  Simply put, that's the date when we plan on finishing the work.  Recently, I asked a developer what his confidence was that we would finish on a date that was two months earlier than the finish date.  I knew that he was working hard to make that happen.  He thought about it and gave me an answer: 75%.

The project manager was confused.  She had a finish date in her schedule that was a couple of months later than the date I asked about.  Was the developer not telling her something?

I explained it this way:

  • The plan is the plan is the plan.  That's the best guess at work, durations, dependencies, etc.  Nothing in his answer changes the plan.  I just slid the date left and asked a question about confidence.
  • That 75% answer would probably change every day, moving higher or lower, if I were to ask the question every day.  You don't want to adjust the plan based on what are essentially mood changes.
  • If I picked an earlier date, the percentage would surely go down.  If I picked a later date, it would go up.  It simply represents a confidence level of finishing on that date.
  • If he had given me a number that was 90% or 100% and had the same answer next week or next month, you would probably want to adjust the schedule to reflect reality.

Here's an interesting exercise:  every week, ask three questions of your project lead:

  1. Confidence of finishing two months early.
  2. Confidence of finishing at the planned finish.
  3. Confidence of finishing two months late.

Track their answers over time.  You can learn a lot by doing this, and sometimes get an early warning of trouble ahead.  For me, the real benefit of this is to see how the answers change over time.  If you're getting honest answers, you'll see how the last week really went on the project.

My Dog, the Project Manager

Friday, August 28th, 2009

Sitting on my bookshelf, in all of its third edition worthlessness, is my PMBOK.  For all of you non-PMI types, PMBOK is the acronym for the Project Management Body of Knowledge, a rather ambitious title conjured up by PMI.  The actual title is "A Guide to the Project Management Body of Knowledge," which is a little less ambitious but still conjures up images of a leather bound travel guide to the West Indies.

I use the term "worthlessness" because in the past year a fourth edition of the PMBOK was published.  Assuming that I knew everything in the third edition, which I didn't despite my handsome PMP certificate, I realize that I am now deficient, lacking the additional knowledge the fourth edition has yet to pass on to me.

The PMBOK is really a Powerpoint presentation expanded into text.  Here's a snippet:

Project Communications Management is the Knowledge Area that employs the processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate disposition of project information. 

See?  It's really a bullet list cleverly disguised as a sentence. Since my copy of the PMBOK is out of date, I am now faced with my own PERSONAL ultimate disposition of project information, namely my third edition.

If you're still reading this, you're probably wondering about the dog mentioned in the title.  I have this idea to shred the third edition and feed it to my dog by hiding the little shredded confetti pieces in his dog food.  Why would I do this?  I could tell people that my dog has ingested and processed more project management information than they will in a lifetime. I could say he passed the entire contents of the PMP exam.  I could say (on his canine resume) that he was responsible for the "ultimate disposition of project information." 

All of which would be absolutely correct, of course.

Finally, since I would replace the third edition with the fourth edition and read said guide, I could know, with no small amount of smug satisfaction, that I was a little more up to date on the PMBOK than my dog.

Project Accounting 101

Thursday, August 13th, 2009

In most accounting systems, you have what is called a chart of accounts.  A chart of accounts is a list of accounts, which are really categories; some for income, some for expenses, some for assets, etc.  When someone spends $150 on an ink cartridge for a laser printer, it might be charged to an expense category called "Office Consumables."  In a double entry accounting system, it needs to come from an account as well.  In our example, let's say it comes from a checking account, which would be an asset account, since it holds real money (one of my favorite assets).

Pretty simple so far.

Let's extend the example a little bit more.  Suppose that four months ago, a project began to develop a new product for your company.  You're the project manager, and you've been given a budget for the project.  Part of your job is to control expenses so that you can see the project to completion within the allotted budget.  Remember that ink cartridge?  It was purchased for the laser printer used by the engineers to print schematic drawings for the new product.  Suppose that in your organization, that expense will be charged to your project.

When you create reports that show the income and expenses that are directly related to your project, you're practicing project accounting.  Costs and revenue associated with your project are typically matched up to elements of your work breakdown structure (WBS), so you can have a clearer picture about where the money is flowing.  This in turn makes you more effective at managing costs associated with your project.

Does your organization track costs by project?  If so, do the software tools (your accounting software, your project management software) in place make this an easy thing to do?  We'd love to hear from you on this topic.  Write to us at blog (at) steelray.com . . .

___

We make the leading Microsoft Project viewer.  Your organization can save thousands of dollars by replacing Microsoft Project licenses with licenses for our viewer for people who only need to view the project schedule.  Why not download a trial today?

When Trends Aren’t Trends

Wednesday, August 5th, 2009

I recently learned an important lesson about trend lines.  Consider an expense graph that looks like this:

Pic1

The values fluctuate up and down month to month.  To smooth out the chart, average expenses over the preceding 12 months (a trailing 12 month average chart).  By doing that, you might see something like this:

Pic2

The rolling average shows a much more consistent picture.

There is a big flaw in this method, though.  Let's add a permanent fixed expense starting in the first June.  When plotting this to a trailing 12 month average chart, you would see something like this:

Pic3

From the chart, it looks like you have a bad trend developing.  It's not obvious from the trend line that you had a large, permanent increase.

The main lesson learned here is to look at your data in multiple ways.  Look at different date ranges.  For example, a trailing 3 month average would have shown a clearer picture in this case.

The Management Part of Project Management

Wednesday, July 29th, 2009

Brandon has a project manager who assigns tasks he doesn’t fully understand, micromanages him, and discourages him from asking questions. Emily has a project manager who rarely checks in with her and only communicates with her about her mistakes. Is your project management style somewhere in the middle of those two examples?  Do you provide your team members with the necessary instruction and enough freedom to prove their mettle, while inserting a net underneath in case they fall?

Good managers maintain the right balance between micromanagement and too little management.   They let the team members come to their own conclusions when something just doesn’t gel, whether it’s an idea, a blog entry, a sale or a teamwork issue. They don’t sweat mistakes as much as they could because they’ve built a team that gives an earnest, determined effort, and takes important lessons from mistakes. Good managers build teams that inspire and earn belief in them.  The manager and team also believes in the product, the service, the organization, and their own abilities.

There are plenty of people out there who will tell you how to be the best manager you can be, to provide the right tools to your team to get the job done. Some of it is easy – like choosing project management software that is compatible with your company’s goals and direction. And some of it is very hard – like putting trust in team members that you aren’t, for whatever reasons, entirely ready to trust.

I can’t help you with the managing part. I can encourage you to look to your own past or present situation and pick out people you worked for that made you feel smarter and more valuable than you did before. Think carefully about their management methods and styles, and see what you can take away to inspire your own change.  Then, start putting what you’ve learned into practice!