Project Management Tips || Project Management, Collaboration and Knowledge Management Blog » tool

Selecting the Right Project Management Software

Brad Egeland — Thu, 15 Apr 2010 09:00:45 +0000

It’s no longer a given that today’s project manager is going to just default to Microsoft Project for all of their project management and scheduling needs. While it remains an industry mainstain, as a standalone tool it’s expensive and offers no collaboration features. Implementing MS Project Server can turn it into a valuable project collaboration tool, but that’s considerably more expensive and not straightforward at all to implement. And today’s PM world abounds with desktop and web-based alternatives that are capable of doing the job for much less.

First, however, let’s look at the big picture. Project management software alone does not make a person a good project manager nor can it ensure that the job is being done well. I believe there’s too much emphasis and too much reliance on project management software – in particular, scheduling software. Some who are relatively new to project management view scheduling software as the totality of project management. This is very dangerous. Although no one can deny the incredible computing power of scheduling software, an inordinate focus on it belies the breadth of the project management discipline. Project planning is so much more than just a schedule. And project management is so much more than manipulating a software tool.

Also, excessive reliance on the tool tends to discount the importance of the “art” part of the project management. Efficient and effective communication along with the ability to manage project resources effectively is the key to project success.

Choosing the right tool

People often the question: “What’s the best project management software?” The standard answer in project management is …it depends. The topic of software selection is no different. It depends upon a number of factors. Here are some of the factors you should consider, examine, and compare before selecting the “right” software for you.

Cost vs. Functionality. The costs and capabilities of project management software vary considerably. Systems can cost anywhere from a few hundred dollars to tens of thousands of dollars. And some newer entries into the desktop and online PM software world can cost as little as a few dollars per user per month. Consider how much power you need with respect to the size of project the software can handle, the features you’re likely to need or benefit from. Make sure you keep an eye to the future: consider functionality not only in terms of what you need now, but for the near term as well.

Capability vs. Ease of Use. There’s a general relationship between the capability of project management software and its ease of use. I once knew a company whose need for computing power in their project management software was not really that great. However, the decision-makers felt that they wanted maximum horsepower in their software, “just in case.” Unfortunately, proper use of the software required sending people off to a week-long, intensive training program and to periodic refresher courses thereafter. The company had difficulty breaking people free to take the training. After two years of hacking their way through the use of the tool, they abandoned it and bought something simpler.

I’ve personally been a long time user of MS Project, but have recently enjoyed checking out other options. I’ve found that offerings such as Seavus’ Project Planner and Project Viewer are extremely easy to use and offer much of the same features of MS Project, but at a fraction of the cost. It also makes it much easier to recommend these types of solutions to smaller startups that I consult with when cost is always a big consideration.

Compatibility with Other Systems. Consider how your project management software will have to interface with other communication, accounting, or reporting systems already in use in your company. Also consider if it even needs to interface at all or if this would be overkill for what you need it for.

Documentation, Startup Support, and Ongoing Technical Support. How much support can you expect from the manufacturer and/or the company selling the software? Consider important issues, such as the documentation you’ll receive, the setup and startup support you can expect, and the long-term technical support you’ll get.

Consider using several sources of input, including the experiences of others and rating guides, before making your final selection of project management software.

Information for this article was derived, in part, from Gary Heerken’s book entitled, “Project Management.”

Related posts brought to you by Yet Another Related Posts Plugin.

Project Communication Series: Project Schedule

Brad Egeland — Sat, 13 Mar 2010 20:06:48 +0000

With the project schedule being so important to tracking the overall status of the project, I can’t guarantee that this is the only article I’ll write in this series on it. There may be more to come – so be forewarned. It’s just that it’s such a critical part of any project whether you’re utilizing it to it’s fullest extent with all tasks, resources, hours, dollars, etc. loaded or whether you’re just entering tasks and dependencies and updating it weekly with revised % complete information. It’s all tracking, it’s all project communication, and it’s all good.

Along with the status call and the status report, the project schedule is a form of communication that needs to happen on a regular basis every week. Just like team meetings and customer meetings that become irregular, if you stop producing updates to the project schedule and delivering them to you team and your customer, they’ll never feel confident that they know the current status of the project. They won’t know if what you’re delivering to them is accurate and current, from last week, or just a best guess.

This goes back to earlier things I’ve written on project management characteristics and being organized and doing what you say you’re going to do. In the project kickoff meeting or during planning sessions on the project, you hopefully set team and customer expectations on the communication aspects of the project. Hopefully, you even produced some semblance of a Communication Plan that documents when you’ve agreed to produce regular communication documents and hold specific meetings. The key is to adhere to those as much as possible throughout the project.

By doing what you said you would do, by adhering to the plans and schedules that were documented and agreed to with the customer early in the project, you build a huge amount of trust and confidence with the customer in your abilities to manage their project and to be reliable. So, back to the project schedule. There is an incredible amount of detail in that schedule if you’re using it to it’s fullest potential. By producing regular updates and delivering it at the same time every week, you build confidence in your team, your customer, and your company leadership that you know what is happening on your project, here is the latest status, and you’re in control.

Here’s my suggesting for using the project schedule during a normal project week:

Review notes from last week’s project status meeting and update the project schedule accordingly
Have a internal team status call (do this weekly on the same day every week)
Use the team information on task updates, issues, etc. to revise the project schedule. Whatever software you’re using, use it effectively. I recommend an easy-to-use and full-featured tool like Seavus Project Planner and Project Viewer.
Deliver a revised project schedule with the weekly status report at the same time every week – preferably about one day in advance of the weekly status call with the customer
Hold the weekly status call and use the project status report and the project schedule as drivers for the communication on the call

Summary

Having an up-to-date project schedule in the hands of your team and customer every week in advance of the project status call can definitely help your status call be more productive. And your customer will have solid confidence in you that you and your team are on top of things and in control of the project.

Related posts brought to you by Yet Another Related Posts Plugin.

Is a Statement of Work Really Important?

Brad Egeland — Thu, 04 Mar 2010 00:26:38 +0000

How important is one document to a project? You know they drill… if you were stuck on a desert island and only had one project document to run with, what would it be? Sure, requirements are critical. I’ve always said that successfully documenting requirements on the project is one of the most critical things you can do. But how do you get there?

In my opinion, the Statement of Work, or SOW, is probably the most critical document you can start off with on a project. It gives you everything you need to start building your project from – of course that’s only if it exists and it’s done right.

Which brings me to my next question. How big or small does a project need to be to warrant an SOW? Is there a dollar amount below which an SOW is overkill? Or is there a minimum project duration below which a SOW would be an extravagance? An unnecessary luxury? My answer here is a definite no.

If a project is handed to you and there’s nothing but some notes on a paper, my recommendation is to stop, refuse to move forward, and request a formal statement of work. If one can not be produced, then I highly recommend building tasks into the front end of the schedule to incorporate sitting down with the project sponsor and creating at least a minimal statement of work document. What you’ll gain from this type of planning up front in the project is invaluable.

I look to the statement of work to provide me – at a minimum – with the following when I’m kicking off an engagement:

General statement of the project purpose or need
Description of the major project deliverables
Definition of the project milestones
Estimation of the project effort
Estimation of the project timeline
Estimation of the project budget (this actually may be specific as it may be set in stone from Sales)
High-level description of the project team roles and responsibilities for both sides
Assumptions for the project

If these things are included in a statement of work document, then the project manager should have enough to get started on planning the project, putting together a draft schedule, and requesting resources for the project effort.

More definition will come out of a formal kickoff session with the customer or project sponsor, but a statement of work that contains at least the above information will set the project manager on the path to getting enough information together to formally kickoff the engagement.

Related posts brought to you by Yet Another Related Posts Plugin.

Should Requirement Quality be Measured?

Brad Egeland — Fri, 22 Jan 2010 23:55:50 +0000

Measuring requirement quality can reveal opportunities for long-term improvements in requirement definition, can show you where to invest for improvements, and can help you develop your team.

Opportunities for improvement

If requirement quality isn’t measured, there will be no future improvement in requirements. Every project – in terms of requirements quality – will be a rerun of the last project. No lessons learned. No forward progression.

Did your last project have rework? Were there any crisis situations in testing? Were there customer complaints? A review of the last project’s requirements may show you how to avoid some of those same headaches on your current and future projects.

Investing in improvements

If you don’t know where the problems are, you can’t fix them. The consequences of requirement errors usually don’t become apparent until late in the development process and then those consequences can be quite expensive and very damaging to your project. It’s easy to confuse them with design errors or testing problems. Given our cultural predisposition toward firefighting, developers will focus on the design or test phase fires caused by these errors rather than the errors themselves. Because the spending rate is higher in these latter phases, managers will focus on putting out fires, as opposed to preventing them. The latest CAD tools or the best test engineers, however, can at most trim the cost of requirement errors, not fix them.

You need to know if your problems stem from bad requirements or from something else. It is not enough to simply allocate 10% of the project’s resources to requirement definition to realize a 50% savings in implementation and test. You must invest the 10% where it will have the greatest impact.

Measuring helps develop the team

As you learn more about where your requirements errors are, you can invest wisely in training project team members. For example, numerous ambiguous requirements suggest that they need training in writing requirements. Lots of omitted requirements signal a need for training in the processes they are writing the requirements for – to create better understanding. Alternatively, instead of process training for people you already have, you may want to recruit people to the team who already possess the proper experience in the area.

Summary

Measurement is the foundation for improvement. It’s unfortunate that managers often feel that measuring requirement quality is complex and expensive. Some feel that it will kill their budget while others feel they can’t measure the quality of requirements until the project is over.

In reality, requirement quality should be reviewed and assessed throughout the engagement. Remember “better, cheaper, faster?” Invest more upfront and achieve better requirements and less rework. But the need to continually assess requirement quality throughout the project is still there – to ensure that the solution you’ll be implementing is what the end user is expecting.

Related posts brought to you by Yet Another Related Posts Plugin.

Doing the Right Things for Your Customer

Brad Egeland — Fri, 22 Jan 2010 01:56:16 +0000

Customers are a demanding group … that’s a given. When we have all of our regular project responsibilities to deal with on a daily and weekly basis, how do we know when we’re doing the right things for our customers? How do we know we’re managing them well, responding to the right requests, saying ‘yes’ when we should and saying ‘no’ when we should, and ensuring that our actions are not detrimental to the forward progress of our project?

You can’t always base it on customer satisfaction levels. Because attentive ‘do-anything-for-the-customer’ behavior may get a project manager and team high marks mid-way through a project. But upon implementation, if they’ve said yes to too many things that ended up modifying scope and delivering a system to the customer that is ultimately not what they ordered, then that customer satisfaction at the end of the project will be low. The end user community will have a product that they didn’t sign up for and that’s a very bad thing.

In order to ensure we’re doing right by our customers, we first need to have confidence in what we’re doing. And we need to have confidence that we’re doing the right things for the project. We can do that in a few ways, including:

Knowing the scope and statement of work inside and out. A very detailed understanding of the project scope and statement of work (if these are two separate documents) will ensure that you can make quick decisions on customer requests. You’ll look confident and your customer will actually appreciate it when you point out their out-of-scope requests if they are in conflict with the goals of the project.
Track issues and risks carefully. Having a good process in place to deal with project issues and project risks as they are identified or realized can help a project team keep the project on track when it would otherwise be derailed. And preparation in this area will help you make good reactive decisions that won’t be in conflict with the project scope and goals.

Effective communication. Keep the customer well informed throughout the project. This may be the single most effective management tool you can use with your customer. If they know what’s going on and where the project stands at all times, their demands and requests decrease and the likelihood that they’ll request anything that can drive the project off course will greatly decrease. If they know you’re in charge and doing it well, they often will leave the delivery team alone most of the time. If you pay for landscapers to take care of your yard, you don’t follow them around with a rake and a shovel, right? You get the point…

Always maintain an up-to-date project schedule. Keep your team and your customer apprised of project status with status reports and meetings, but having a schedule in their hands every week that makes them understand where things stand on the project is invaluable. Lots of tools project management and scheduling software tools are available for this including Seavus’ Project Planner web-based tool.

Summary

It’s not always about doing everything your customer wants. In fact, that’s usually not advisable. It’s about having confidence in your own ability to manage their project, keeping them informed with the right, accurate information using the tools you have, and always keep the scope of the project and the end goals in mind. After all, it’s always about delivering a usable product to the customer’s end users – that’s where the true customer satisfaction game is won.

Related posts brought to you by Yet Another Related Posts Plugin.

Good Requirements vs. Rework – Part 3

Brad Egeland — Fri, 15 Jan 2010 18:45:27 +0000

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner. Please visit their site for more information.

As we concluded Part 2, we discussed what we all really already know – that bad requirements usually lead to cost or budget overruns, project timeframe slippages, frustrated and overworked employees, dissatisfied customers, lost profitability, and quite possibly shortened tenure with your company.

The ultimate cost of requirement errors and omissions can be huge beyond just the rework factor. Requirements drive more than just project and product quality. They drive product end-user usability. They drive the personnel skill levels for both product development and operation. They determine how the product will be used. Requirements for ease of operation, for example, lead to products that require less training before use and less time to accomplish tasks. Omitting operability requirements will result in a product that is inexpensive to purchase but costly to use. Worse, end-user operators may make more mistakes in the product’s use.

If you increase your investment in requirement definition, what return can you expect? Studies conducted by NASA in 1991 and 1992 revealed average cost and schedule overruns of approximately 65% in 29 programs. Their findings indicated that those projects that invested 10% or more of their total resources before freezing requirements had 0% to 50% overruns. For projects that spent 5% or less on requirements definition experienced 100% to 200% cost overruns.

Public projects are often larger and affect more people than private sector projects; this fact, and the obligation of our government to be open with the public, results in most project failure headlines being about government projects. These headlines can give the impression that government administrators are not managing projects as well as their private sector counterparts when this is not likely the case. Just as many incomplete, over budgeted, and ill-conceived products exist in the private sector as in the public sector – they just don’t get the same amount of press.

Conclusion

Public or private, for-profit or not-for-profit, service or manufacturing, it doesn’t matter what your industry or product. Good requirements are crucial to a project’s success. Project managers from all areas must take responsibility for ensuring quality requirements. If you are managing an effort to define requirements for a procurement, requirements are your first product. If you are directing the procurement, the requirements guide the purchase. If you are managing the development of the product being procured, the requirements guide the development effort.

If your product is a service, defining the requirement to be met is just as important in the consumer’s perception of quality as when your product is a physical object. It will be tempting for those whose product is not specifically a set of requirements to say, “I don’t write them … I just have to meet them.” When all is said and done, however, the customer or end-user will not separate the blame for failure to meet their expectations. The finest design, workmanship, and materials will still be labeled poor quality if it fails to do the job for the customer. Everyone in the chain from product or project concept to realization must concern themselves with the quality of the requirements. Project managers must set the pace for their team and company in this effort.

Related posts brought to you by Yet Another Related Posts Plugin.

Good Requirements vs. Rework – Part 2

Brad Egeland — Fri, 15 Jan 2010 05:39:13 +0000

This article is based on information from Hooks and Farry’s book entitled, “Customer-Centered Products.”

“Better, cheaper, faster!” Remember how we discussed that in my previous article and closed out with the good news that “better, cheap, and faster” is actually possible?

Now the bad news: You have to change your approach to project and product development or procurement in order to realize “better, cheaper, and faster.” Repeating the mantra is not enough. Nor is it enough to tell your requirement definition team to simply “write better requirements.” If that was all it took, we all would have done that long ago. You, as the project manager, must identify the areas needing improvement and empower your people to change. Only a manager can eliminate many of the causes of bad requirements. The seeds of schedule and cost overruns as well as operational failures are planted early in projects, typically with pressure, often from management to procure or begin developing a product before fully defining it’s needs and use.

Customers frequently do not understand their own needs before engaging a developer. When customers do understand their needs, they may not communicate these needs clearly. Sometimes customers describe a possible solution to their needs rather than the needs themselves. Developers make assumptions about the customers’ needs and do not check their assumptions with the customer before charging into development. It is this type of rogue development practice that can get a project in to trouble quickly. Customer expectations drift while the development or procurement is underway.

Sometimes the original requirements are too ambitious for the budget and schedule. The requirement risk assessment before development start is inadequate. Partway through development, it becomes clear that the original requirements cannot be met. The descoping and redefining process involves scrapping much of the development work done to date, or procuring an entirely different product.

Even worse is the situation when the product enters acceptance testing before the miscommunications become apparent. The customer finds that the product does not meet their needs and reject it, often citing a huge list of “bugs.” These are bugs only in the context of the customer’s needs. They are mismatches with the customer’s expectations, not technical flaws in the product. Still the development team must redesign and rebuild the product or solution to meet the customer’s now all-to-clear needs. Much of the work that went into the first product, the product that did not meet the customer’s needs, is wasted.

Bad requirements result in cost overruns, schedule slips, frustrated and overworked employees, lost profitability, and limited careers. All else being equal, high-quality requirements contribute to high-quality products completed on schedule and within budget. Quality products begin long before manufacturing and testing. They begin before design. Never will you have more leverage – dollar for dollar – on your product or project’s quality than you have in the requirement definition phase.

In Part 3 will further discuss the benefits of having good requirements in hand at the beginning of the project.

Related posts brought to you by Yet Another Related Posts Plugin.

Good Requirements vs. Rework

Brad Egeland — Wed, 13 Jan 2010 19:50:57 +0000

This article is based on information from Hooks and Farry’s book entitled, “Customer-Centered Products.”

“Better, cheaper, faster!” “I want it yesterday!”

Everyone out there has heard one or more of these – how and when you’ve heard them depends on your industry. But they translate into the same headaches for everyone. If you are a product development manager, you must develop and deliver higher quality products in less time and for less money than you have in the past. If you are in charge of procuring products for use in your company, you must procure a quality product faster and cheaper than ever before – especially in this economy. Otherwise, you may not be able to stay in business.

Many of us have been struggling with using the words faster, better, cheaper in the same sentence. Conventional wisdom says that you must sacrifice “better” to get “faster” or “cheaper,” not to mention “faster” AND “cheaper.” You probably grew up with ads saying that “quality takes time” and “you get what you pay for.” You may have recently been on a project in which someone above arbitrarily cut your budget or reduced your schedule or both, and yet they did not lower their expectations of the final output – and they may have even increased it. If so, you know that you can’t get there by simply driving your people faster or even adding more people to the project (which would make the cheaper part impossible anyway).

If you are a development manager, you are already streamlining manufacturing and testing processes, reducing material waste, increasing process yields, and automating the most labor-intensive or operator error-prone steps. These steps reduce time and cost and improve quality, but they usually do not lead to breakthrough savings or revolutionary quality improvements. The savings are limited by the product design. What drives design? Product requirements: the needs the product must meet to be a success. Increasing your investment before product design or purchase – ensuring that you have a complete, correct set of product requirements in the eyes of all stakeholders – is the real key to better, cheaper, and faster product development or procurement.

Consider one of your recent projects, product developments or procurement efforts. What requirements did the effort start with? Were these requirements clear? How many times did they change? Did crises occur during developmental testing? Did you discover that you had missed or misunderstood a requirement in acceptance testing? Did operations deployment go smoothly? You may be shrugging the problems off, thinking, “No worse than usual.” Or saying, “That’s just the nature of project management or product development.”

If you are a typical manager, your culture may blind you to alternatives. “Never time enough to do it right, but always time enough to do it over” is not just a joke. It’s ingrained into our culture. Reconsider for a moment: Does development rework resulting from misunderstanding the users’ needs add to the final product’s quality? Do the delays caused by that rework or unanticipated manufacturing or testing requirements add anything to the product’s performance in the field? Do product features that your users don’t need add to their satisfaction? No. Do they add to the development time and cost? Do they add procurement and installation costs? Yes. One study found that approximately 40% of the total budget for software projects was actually spent on rework. Another study found that the rework cost on the largest software projects can often approach 50%.

Now for the good news

The good news is: “Better, cheaper, faster” is actually possible. Eliminating rework and the eliminating the inclusion of unnecessary features rooted in poor requirements definition can make projects and product development faster and cheaper without sacrificing better. At the same time, improving the fit between the product or solution and the customer’s needs also makes it better. You can frame the structure of success – good requirements – early in a project. Start with good requirements, and win on quality, cost, and schedule.

Related posts brought to you by Yet Another Related Posts Plugin.

A Nine-Step Process to Requirements Definition

Brad Egeland — Mon, 04 Jan 2010 06:30:16 +0000

Until a few years ago, the requirements definition process was only briefly discussed in books that addressed project management, systems engineering, and software engineering. Many texts assume that the requirements are a given and show the requirement definition process as a single step on a waterfall chart. Most college curricula never even address the subject of requirements, much less the requirement definition process. Books devoted to requirement definition finally began to appear in the early 2000’s. Some outlined complex requirement definition processes, but more complex is not necessarily better. Most, if not all, of the benefits of a complex requirement definition process come from a few key steps. Overly complex processes use significantly more resources than simple ones do without significant incremental gain.

Use What You Have

In your search for a suitable requirement definition process, don’t overlook your own organization. If you are in a large organization, a good requirement definition process may already be in use somewhere in the company. If so, adopting it will capitalize on experience in your own organization and make management across projects easier. It’s possible that a requirement definition process from another part of your own company is already tailored to your product or project needs.

A Nine-Step Process

If your organization doesn’t have a requirement definition process already in place, then here’s a simple starting point. Below is a practical, nine-step process for defining requirements for your project or product:

Scope the project or product by defining needs, goals and objectives, mission or business case, high-level operational concepts, customer requirements, constraints, schedules, budgets, authority, and responsibility.
Develop operational concepts – scenarios for how your project or product might be used by the end user. Expand the concepts to cover all phases of the product or project life cycle.
Identify interfaces between your project or product and the rest of the world, clarifying boundaries, inputs, and outputs.
Write requirements to guide product design toward what your customers need and want.
Capture rationale (the reasons for the requirement’s existence) behind each requirement and expose potentially dangerous assumptions and incorrect facts.
Level requirements according to system and system sub-divisions, ensuring that all requirements are written at the right level and can be traced back to their origins.
Assess verification of each requirement, identifying the verification technique and facilities and equipment required.
Format requirements and supporting documentation to ensure that you have included each of the appropriate types of requirements and that your development team members can find all of the requirements they must meet.
Baseline requirements after validating that they are correct, complete, consistent, meet the project scope, and do not add unnecessary functionality or features not covered by the original scope.

Note: Information for this article was derived from the book “Customer-Centered Products” by Ivy Hooks and Kristin Farry.

Related posts brought to you by Yet Another Related Posts Plugin.

Measuring Project Progress

Brad Egeland — Thu, 31 Dec 2009 19:28:19 +0000

A section of Eric Verzuh’s book “The Portable MBA in Project Management” provides the basis for much of this article.

Measuring Progress

The key to finishing a project on time and on budget is to start out that way and stay on track throughout the project. When project managers start with challenging schedules and then fall behind, even by a little, they spend the rest of the project trying to catch up. Other projects, however, seem to have a self-correcting process built into them; if they fall behind a little, the problem is quickly identified and dealt with immediately. Progress measurements are the tools we use to identify problems when they are small and there is still time to catch up. Because cost and schedule progress comprise two-thirds of the cost-schedule-quality equilibrium, they are the primary focus of progress measurement.

During each reporting period, the project team records actual start and completion dates for each task in the WBS, along with the actual cost incurred by each. This data is then compared to the cost and schedule baseline to evaluate project team performance against the plan.

The primary tool for illustrating a schedule is also good for displaying schedule status. Of course I’m referring to the Gantt chart – something no project manager leaves home without. A summary-only Gantt chart can be a useful tool for reporting schedule progress to high-level management or customers who are not interested in all the details. The focus in a summary Gantt chart is on displaying schedule status. To get actual task completion status, the project manager must communicate with those working on the task.

The truth about cost and schedule status is often elusive because it is hard to pin down what portion of a task or project is really complete. Many a project has fallen into the trap of subjective assessment of progress. Subjective assessments—a gut feeling from the project manager or team members—tend to be overly optimistic early in the project. Even as the project passes the halfway point in the schedule, if we rely on intuition or how we “feel” about the project, the assessment often turns out to have little relationship to reality.

Few organizations admit to running their project by the project manager’s “gut feeling,” but their assessment methods are far from objective. Project managers may be asked to give a project a rating of “green, yellow, or red” to indicate their confidence or need for executive involvement. This subjectivity multiplies when considering a portfolio of projects. As manager of 10 or 100 projects, how do you really know the status of each one? If you have a subjective assessment of how your projects are going, how do you compare one project to another for making decisions on your project portfolio?

Summary

Relying on the project manager’s assessment of project status based on feedback from task owners is more subjective than objective, unfortunately. And that is the basis for overall project portfolio status in the case of many top organizations. Diving further by using earned value analysis methods can yield more detailed project status results, but not without additional costs and efforts. The key is to try to use some sense of reality when measuring project status and percent complete on tasks. Being overly optimistic serves no good purpose for your customers or for your organization.

Related posts brought to you by Yet Another Related Posts Plugin.