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

By Laura Bamberg – Global Sales Administrator

Steelray Software

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 used!

Easier Maintenance Renewal Is Possible!

By Laura Bamberg – Global Sales Administrator

Steelray Software

When the time for maintenance renewal on your project management software crops up, do you ever wonder if you've made the right decision by sticking with the version you already have? If not, have you experienced the confusion of checking out website for product maintenance information and pricing?

If you are nearing your software renewal deadline, don’t look at products whose benefits aren’t immediately clear, and don’t consider companies that aren’t up front about cost. It is a given that quality plays a critical role in project management software, but how can you trust a company that isn’t transparent about pricing? What does that say about quality?

So what sets our Microsoft Project viewer license apart? Project management software has some commonality. But how well do they work on a consistent basis? Can they support the number of users you have to supply? Are the account managers honest, trustworthy, and knowledgeable? Can you rely on the company's technical support staff? If you have experienced situations with your software vendors that lead you to answer “no” to even one of these questions, I advise you to take a look at Steelray Software.

Tom Barnes, a sales representative here at Steelray, draws a connection between cost and value. “When assessing software maintenance costs, you want transparency in pricing and stability in your ongoing costs. A quick search will show a wide array of pricing modes - free, licenses plus maintenance, annual subscriptions, monthly subscriptions, and then some. It can be hard to pick which one. I know what you are saying - you said free - I’ll take that one.”

But Barnes throws out a word of caution because he knows that with respect to quality, free software is like a free lunch – it does not exist. “What does free really get you? Support? No. New releases? Yes, but you are at the mercy of the development community.”

Barnes said that when he first came to Steelray, he wondered why the company charged for annual maintenance and support, but quickly learned why. “We have exceptional support,” he said. “You can contact us by e-mail, through our website and yes, you can even call. I was also surprised to learn how frequently we have new releases (at least once a quarter).”

He went on to say that he was even more surprised to learn that these releases contain new features, compatibility with new file formats and the occasional bug fix. “For $6.29 USD each a year, that is a lot of value. And by the way, that pricing hasn’t changed in years.”

For those who are already loyal customers of Steelray Software, Barnes reminded them to consider co-termination of their licenses. “It can make your renewal period more consistent. And if you discover that you need either more or less licenses than you currently have, our EasyLicense program is a favorite of many. “

But if you haven’t tried us out yet, and it’s time to renew your maintenance on project management software, you should download our free, 10-day trial key. When you do, you will see how incredibly inexpensive it is, while at the same time, providing the kind of features you really want to use – ones that promote ease of use and integrate into a program that takes virtually no training to use.

Why a Change Order Isn’t the End of the World As We Know It

By Laura Bamberg - Global Sales Administrator

Steelray Software

I have a friend who recently needed a change to a project made, and the Development department told her it would take them four days to make the change, even though she felt it should only take them two days. With a client breathing down her neck, this made her understandably frustrated. A simple change order could have resolved an issue that might have led to a possible loss of trust by one of her company’s largest clients.

Her company does not use a Microsoft Project Viewer software – to her detriment in this case. If she did use Steelray Project Viewer, this situation could have been more easily solved. How? Keep reading . . .

Change orders can be a real pain, but they are necessary. In Clarise Z. Doval Santos's post - The Importance of Scope Planning in Project Management – she states that, “[e]veryone affected by the project must understand that there is a process and even an associated cost for any scope change. The Scope Management Plan should be part of the Project Plan.”

We know this to be true, of course, but there are differing opinions on how detailed the scope change orders have to be.

“Any changes that are required during the life of the project must be formally planned and controlled to ensure that the impact of change stays within agreed parameters; there should be a documented change control procedure,” states the UK’s Office of Government Commerce in Introduction to Project Management Processes - Change Control and Issue Management. “The cost, time and quality parameters associated with the project should be established before implementation and monitored throughout the life of the project. All proposed changes should be costed and their effect on the overall project established before they can be authorised to go ahead.”

Xiaoming Wang posted a blog entry stating change orders should be more “goal-driven and not too detailed so that the team can be more creative during the implementation.”

Whatever your take on how comprehensive these change notifications need to be, suppose you operate as my friend’s company does. Now visualize that your project manager (or the person operating in that capacity - see our blog entitled Why Purchase Project Management Software?) uses Microsoft Project and can supply Steelray Project Viewer to his or her team. The project manager doesn’t want the team members to modify the project file but does need updates on their tasks. The manager writes the mpp project file in Microsoft Project Viewer and gives it out to his team via Steelray Project Viewer. Team members are then assigned their tasks with three update choices.

One of those choices is that the status of the task is “in process.” During the processing phase, you can edit the task,and the team member could have notified my friend with an update saying it will take four days, and there is no way it can be done in two. The project manager can then investigate and make a more realistic change order.

There are many reasons to use a software applications like ours. When it affects the status of your client relationships, it’s a no-brainer.

Join the discussion at http://www.steelray.com/discuss/ and let us know what your issues have been, and how software such as Steelray's has helped you solve them, or how we can do it better. We’re always listening!

Possibilities and Results

By Brian Leach, Managing Director/Owner
Steelray Software

At the beginning of your project, there is nothing except possibilities. If you're good (and lucky), you'll have clearly defined objectives and deliverables. Of course, the parts between the beginning and end of the project are the "make or break" for the project's success. A lot of things must go well, but three things jump out as absolutely critical to the success of a project.

Planning. So much has been written about the importance of planning, and yet . . . this is the phase where corners are often cut. Plan everything you can. Plan the work that will be done. Plan for the things you know of that might go wrong. Plan for the things you don't know of that might go wrong. Imagine all of the scenarios that might be thrown at you, and think about how you'll adjust.

Vigilant Monitoring. If you're not checking in with everyone at frequent intervals, small problems become big problems. In a project, no news is not necessarily good news. Use any and all communication methods at your disposal to check in with the team to discover the real status. Good relationships are a critical success factor in this phase.

Response to Change. Change happens. Projects are dynamic, and even the best plans require adjustments. Make sure that you have a sensible process and an open mind about change.

There are many words of wisdom in the book Kiss Theory Goodbye by Bob Prosen, but I can use these to make my point:

Realize that at the beginning of the day, it's all about possibilities; at the end of the day, it's all about results.

Replace the word "day" with "project" and we have:

Realize that at the beginning of the project, it's all about possibilities; at the end of the project, it's all about results.

With proper planning, unwavering vigilance, and an open mind toward change, your results just may fulfill the best of your possibilities.

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!