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!