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.
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:
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?
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.
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:
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!
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!
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:
Here's an interesting exercise: every week, ask three questions of your project lead:
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.
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:
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.
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?
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.