Project Management Scratchpad

Project Closeout

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

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

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

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!

Stake your Project Claim

Laura Bamberg – Global Sales Administrator

After recent conversations with a friend about waffling company policies on projects, my head was whirling. I wondered how you manage a project without the stakeholders’ approval or buy-in?

As a short side note, the project sponsor can sometimes be the customer, but ostensibly, it’s the person paying for the project. The stakeholders include anyone affected by your project. The project team, the sponsor(s), the end-user – these people are all a part of the project.

In my friend’s company, the sales representatives sometimes create quotes based in large part on what the customers want, and not always on what their products can do. The next step in the process is a layer of approval from several colleagues, and in many cases, the sales representative in question has to go back to the customer and renegotiate. You can imagine how the customer feels.

What’s worse, at times, the deal is so tightly made already that the company is compelled to almost entirely re-do their own products or services to customize the needs of one client. All you project managers out there are cringing, aren't you?

Either way, a lot of people in this company are frustrated most of the time. Rarely can the project manager actually close a project on time, because there are too many changes and delays along the way. The project team is constantly being shifted about, forced to sacrifice the product’s quality at times.

Hopefully, this doesn't hit close to home for you. This blog could accommodate a lot of project management verbiage, but for today I’d like to focus on stakeholders. What are their expectations, and how in the world could a company that operates at this level of mayhem meet them?

Be Firm

Many projects begin with the stakeholders’ expectations making you feel frustrated and overwhelmed.  How can you ensure they’re all completed? The short answer is – many times you can’t. At some point, a line has to be drawn, and on it are written the words – this is as far as we’re willing to go. We don’t have the resources to do everything you want. But we’re glad to have your suggestions – we can definitely keep this in mind for future projects. I bet that graphics idea (which would take about a year to implement) could be used in part on our next version.

Be up-front with your stakeholders. Let them know that before the project plan is implemented, you need to know what they want, but you also need them to know that you can't promise them everything.

Use Metrics

Not only do you need to collect your stakeholder requirements – you need to be able to turn them into project management metrics. Here at Steelray, we’re very focused on metrics for our own business needs. They can be pretty useful if they’re truly measurable.

As an example, suppose your project involves developing a new industrial pressure treatment for wood. Stakeholder requirements could sound something like this: Does it look good? Is it easy to use?  Over the course of the project, many more could be added.

You definitely don’t want customers to think your pressure treatment damages the wood it’s used on, or changes a beautiful color into an ugly one. But how measurable are these requirements?

What if the stakeholder requirements encompassed some of the following:

• Does it change the color of the wood?

•  How long does it last?

•  Are there environmental regulations that would be broken during disposal?

Not only does this encapsulate what the stakeholders asked for – it also provides them with metrics they can use during the course of the project, and especially at the end. I think it’s a given that you’re actually expected to follow through with them. Be sure to add this to Lessons Learned post-project if it's the first time metrics have been given!

The Best Software I've Ever Written

By Tom Ollar
Steelray Software

The software industry is still young – and contention regarding every aspect of the development process reigns supreme. With one man’s method decried by another as madness, it is sometimes difficult to see the forest for the trees; one thing is certain, customers like software that works – they even appreciate that mysterious quality computer scientists sometimes refer to as ‘robustness,’ though isolating it in the lab can prove difficult. In short, quality is hard, but achievable and certainly desirable. My story of one small quest for quality follows . . .

In 2003 I sold my half of Digital Metaphors Corporation, acquiring the rights to iSpace. iSpace was nothing more than the design for a new kind of Office application, one focused on 'end-user reporting.' iSpace was targeted to do for reporting what Visio had done for diagramming. The 'end-user designer,' long a strength of ReportBuilder, had received continuous feedback from developers and their customers over the years, pointing to a potential market for a totally stand-alone version, albeit one toned down for 'real' users.

Consisting of over 300 Design Plates and a 40-page document describing every aspect of the application, the iSpace design was daunting. The user-interface itself was simply not possible using stock controls, and yet the key competitive advantage of the product was this very interface. So Jim Bennett and I (the other lead engineer that left DM with me), dove deeply into the UI area. We desperately wanted to use C# in lieu of Delphi, as we felt the managed aspects of the environment would far outweigh the performance hit. Ultimately this would prove incorrect, but at the time, it seemed oh-so-compelling.

Our first crack at it was .Net WinForms - even with liberal doses of 'CustomDraw' we hit roadblock, after roadblock - our 'prototypes' were ugly and misbehaved. It looked like the UI, our key competitive advantage, was going to elude us. Then one day, as we mulled over a garish, Win 3.1 style scrollbar, Jim mused 'why don't we do our own scrollbar, I mean, how hard could it be?' That phrase 'How hard could it be?', though the answer again and again was 'Really, really, really hard', became our siren song as we proceeded to knock off control after control. A year and a half later, we had a state of the art UI platform that supported 15 different controls, including a fully-virtualized ListBox and ListView (read virtualized here as 'unlimited rows - still scrolls').

We built the platform painstakingly, unit test by unit test - only, these were not your typical unit tests, these tests literally ran each individual piece of a control, asserting the resulting offscreen bitmap for correctness. If even a single pixel was off, the test would fail. At the end we had over 15,000 such tests, and even when run in 'full-speed playback' mode, these took over 3 hours to complete on our best machine.

Technically then, we were in rare air. How many other developers in the world had built a full-fledged UI platform? How many had done this much unit testing? How many had ever done any unit testing with UI - period? Indeed, when we started talking with other developers it seemed most didn't see the need for unit testing, much less UI unit testing. And yet, with only two developers, in less than a two year period, with no public or private beta, we had built a complete, shippable, production quality UI platform.

Though we did not ultimately build iSpace (the original dream application that guided our work), blix (the resulting UI platform) went into production at various clients around the world. Not only has it performed amazingly well, we have, on occasion, returned to enhance it, add a few tests, and re-release. It's hard to describe the feeling you get watching 15,000 tests go green - but 'good' certainly applies.

From a business standpoint, quality meant that we had something more than code – we had an asset that could be used and re-used. All too often code bases are tempered against the back, neck and foreheads of poor ‘users’, and whether suspecting (beta) or unsuspecting (release), it’s often hit or miss and never as nice as a simple cheer from the crowd. That such a cheer might be achievable using engineering methods for QA might be brilliant. Then again, it might be madness too . . .

---

Steelray offers a free trial of the leading Microsoft Project viewer.  Download a copy today!

The Confidence Question

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

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

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

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

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:

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:

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.