Inside Project Management

Features :

2008-03-19T21:27:00.001-07:00

Basic Considerations In Buying Project Management Software

The cost range of project management software is huge. From under $50 to over $20,000. Extensive reviews have been written about all the different software packages and it is far too complex to summarize in a short article, but following are some general guidelines to help you narrow down the decision making process.

Start by determining the size of the expected project(s) and number of projects. Quite simply, the larger number and more complex projects will justify more complex and expensive software……read more>>

Tips To A More Effective Project Management

Gillian is at the end of her wits! They only have less than three months to finish the project and yet all things seem to be going wrong. And to top it all, there's little financial resources left to finish all things that needed completion before d-day!

To an expert's eye, Gillian's problem all boils down to improper project management. She may have started the project without evaluating all her resources and whether or not these resources will be enough to meet all the requirements of the project….. read more>>

Managing your website development – eight easy steps to project management

Managing your website development need not cause you sleepless nights providing you learn the secrets of successful project management. Perform the best practices in project management and give your project the best chance of success……. read more>>

The Project Management Mindset

Project management as a science and art is undergoing key transformations as a result of countless stories of failed projects, cost overruns, and canceling that project that took 2 years of your employee's lives. Needless to say, these scenarios not only cost money, time, and lost opportunities, but also have a longer term impact on the overall morale of a workforce……... read more>>

Simple Mistakes You Cannot Afford In Project Management!

Sometimes... Management claim they want this and that change... ..And sadly enough too... sometimes... When you start giving it to them - they start sabotaging you

And unless you're pretty aware of that when that starts happening - and unless you take measures to do something about it - you're headed for danger... Big Danger! …… read more>>

Why Your Headline Will Make You Or Break You In Project Management!

The value of a proper headline when dealing with a project (or anything else for that matter) cannot be stressed enough...

Yep! I'm talking of the headline of your email correspondence here...

It only makes the day for a project manager so much more comfortable (not to mention easier), when he/she has to find something in a hurry... …… read more>>

Project Management Success with the Top 7 Best Practices

Managing a project can be daunting. Whether planning your wedding, developing a new website or building your dream house by the sea, you need to employ project management techniques to help you succeed. I'll summarise the top 7 best practices at the heart of good project management which can help you to achieve project success. …… read more>>

A Project Management Rule: Collaborate

Really collaborate. Make it your rule to plan with those people who will be the performers of the plan. Don’t wait ’til the project has gone south to get their help. Start out that way. Continue collaborating as the usual way you work through the project.

Do your workplans, resources, and performance metrics offer a solid readout of what is going on with your projects’ performance? Do you Plan your Work then Work your Plan, or are you simply envious of those who do? …… read more>>

Basic Considerations In Buying Project Management Software

2008-03-17T07:48:00.001-07:00

Start by determining the size of the expected project(s) and number of projects. Quite simply, the larger number and more complex projects will justify more complex and expensive software.

Small Projects

Smaller, infrequent projects often can be handled with no specialized software. Gantt charts can even be constructed with Excel. Remember though that even if your projects are small at this point, if there is a possibility that your business will grow, it may make more sense to invest the time and money in a more advanced software tool.

Suggested packages at this level include Milestones line of packages. Prices range from around $50 up to $240. Turboproject has versions under $50 up to $300. For somewhat more complex packages consider Microsoft Project at $200 to $600 or Primavera Suretrak at $400 to $600.

Medium Sized Projects

Budget becomes more of an issue as project size increases. This requires software with greater flexibility and more complex relationships. The other elements of resources, time, and scope grow substantially in medium sized projects. The previously mentioned Microsoft and Primavera packages are good choices at this level.

Large Multiple Projects

With multiple large projects resources need to be carefully allocated and prioritized. Several layers of management will be involved and the entire project management process will often need to be integrated into various departments of the organization including payroll, human relations, accounting, etc. In order to accomplish this, the project management software will need a great deal of flexibility and possibly even some customization.

Choices at this level start with the medium sized packages and go up to the highest versions of Primavera. Often network versions are used which enable multiple users contributing to the projects.

Author: Neal Williams

Neal Williams is a Project Management Professional. More information can be found at his http://www.best-project-management-software.info website and his http://www.pos-software-sources.info site.

Tips To A More Effective Project Management

2008-03-17T07:47:00.000-07:00

Project management is the process of applying one's know-how or knowledge in overseeing and managing a project of whatever magnitude. Do not think that project management is required only by big projects. Small projects can also benefit from an effective project management. Knowing how to use and apply the knowledge you have acquired in all areas will be helpful in the implementation and accomplishment of any project.

Scope of project management

Project management covers all the areas necessary to see a project into completion such a finances, administrative work, communication and public relations. Project management includes but is not limited to:

1. The development of a project plan- The project manager must talk to the project creator before accepting or starting a project. They must agree on specific terms of the project so as to avoid conflicts and unreasonable delay in the future. Make sure you know what needs to be done and in what time frame. Ask for specific results that the creator wants to arrive at so you would know what to expect and you will have a gauge as to whether or not the project was managed properly.

2. Definition of the scope of the plan- Once the terms of reference has been agreed upon, the project manager must make a project plan which contains all the things necessary to start and complete the project. List down all the resources and logistics you need and the available human resources. Make a map of the project, from start to finish. Make the map realistic so you can avoid problems later on.

3. Creation of a project schedule-A timeframe for your project would help you map out the exact schedule required to start and end the project. Create specific time schedules for each step of the project so that would know if you are ahead of your schedule or whether you need to hasten things up to meet the desired schedule.

4. Acquisition of human resources- Aside form good planning. A good project management relies on the acquisition of efficient and able human resources. The project leader may be doing all things possible but if he is surrounded by an inept staff, then he will have more problems than he can handle. A project's human resources must be informed of the project schedule and deadline so they will know what is expected of them. Try to motivate your staff and praise each accomplishment no matter how small.

5. Development of a communication plan and good public relations- Project management includes the creation of a good communication plan which will enable the efficient flow of information from the leaders to the staff and to the stakeholders. The communication plan must make sure that all information related and affecting the project are relayed to the proper person or office as soon as possible to avoid delays and misunderstanding.

A good public relations plan should also be put into place, particularly if the project has a positive or negative impact to the community. So many projects have been stopped in the middle due to pressure from the public. It is better to inform the public on the advantages and disadvantages of the project at the start of the plan so as to avoid conflicts later on.

Proper project management is not really complicated but it requires had work and proper planning to make everything smooth, from the start to the completion of the project.

Author: Robert Thatcher

Robert Thatcher is a freelance publisher based in Cupertino, California. He publishes articles and reports in various ezines and provides project management resources on http://www.aboutprojectmanagement.info.

Managing your website development – eight easy steps to project management

2008-03-17T07:46:00.000-07:00

Define objectives

Objectives guide everyone on the project to your final goals. Are your objectives to sell your product online, to provide customer support, to promote investor relations? Carefully decide and clearly document your objectives.

Decide the critical success factors – the things at the end of the project which tell you if you’ve been successful. Make them measurable so you know if you’ve achieved them. For example, the website development should result in an increase in online sales of 25% by year end.

Stakeholder analysis

A stakeholder is someone with an interest in your project’s success (or failure). Decide who they are and whether they support your project. Perform stakeholder analysis by classifying them (high or low) according to how motivated they are in helping (or blocking) your project and how influential (high or low) they are.

Highly influential and supportive people are your allies. Gain their support whenever you can. Aim to reduce the influence of people who are both highly influential and against your project as these people could act to damage your project.

During your stakeholder analysis, draw up strategies for dealing with each group of stakeholders.

Define deliverables

Deliverables are tangible things produced during the project. Talk with key stakeholders to help define deliverables. Will your website design include web page layouts and sitemap for use by the programming team? What is the content for each page? Write all this down.

Key stakeholders must review and agree the deliverables accurately reflect what they expect to be delivered.

Project planning

Define how you will arrive at your objectives. This involves planning how many people, resources and budget are required. If delivering this in house, decide what activities are required to produce each deliverable.

For example, you might decide a web designer will develop page layouts and navigation diagrams. You might decide the marketing team will supply all product details and photographs. You might decide the finance manager will set up merchant and payment gateway accounts to enable e-commerce transactions via your website. If outsourcing work, specify exactly what the sub-contractor should deliver.

Estimate the time and effort required for each activity and decide realistic schedules and budget. Ensure key stakeholders review and agree the plan and budget.

Communication planning

Hold a kick off meeting with the team and explain the plan. Ensure everyone knows exactly what the schedule is, and what is expected of them.

For example, the web designer needs to know that he is to produce page layouts and navigation diagrams based upon the marketing manager’s requirements. He needs to know his expected start and end times.

Share your project communication plan with the team. This should include details of report templates, frequency of reporting and meetings, and details of how conflicts between teams and their members will be resolved.

Project tracking

Constant monitoring of variations between actual and planned cost, schedule and scope is required. Report variations to key stakeholders and take corrective actions if variations occur. To get a project back on track you will need to juggle cost, scope and schedule.

Suppose your programmer hits technical problems which threaten to delay the project. You might recover time by re-organising or shortening remaining tasks. If that’s not possible, you might consider increasing the budget to employ an additional programmer, or consider reducing the scope in other areas.

Be aware that any adjustments you make to the plan might affect the quality of deliverables. If you need to increase the budget, seek approval from the project sponsor.

Change management

Once started, all projects change. Decide a simple change strategy with key stakeholders. This could be a committee which decides to accept or reject changes which comprises of you and one or more key stakeholders.

Assess the impact of each change on scope, cost and schedule. Decide to accept or reject the change. Be aware that the more changes you accept the less chance you have of completing the project on time and within budget unless you reduce scope in other areas.

Suppose the marketing manager wants to add a popup window to display full size photographs of products. Assess the impact of this change. You might need to remove some remaining tasks to include this change and stay within budget. Or, it might be impossible to include the change without increasing the budget or schedule.

Don’t blindly accept changes without assessing the impact or your project will overrun.

Risk management

Risks are events which can adversely affect the success of the project. Identify risks to a project early. Decide if each risk is likely or unlikely to occur. Decide if its impact on the project is high or low.

Risks that are likely to occur and have high impact are the severest risks. High impact but unlikely risks, or low impact but likely risks pose a medium threat. Unlikely and low impact risks pose the least threat.

Create a mitigation plan of the actions necessary to reduce the impact if the risk occurs. Start with the severest risks first, then deal with the medium risks. Regularly review risks. Add new ones if they occur.

Suppose the marketing manager cannot decide what he wants from the website. Without knowing what the marketing manager wants, the team cannot deliver a website to meet his expectations. You assess this risk as highly likely to occur and having high impact. Your mitigation plan might be that the web designer develops page layouts to be reviewed by the manager early in the project.

Summary

Performing best practices in project management will give your website development project the best chance of success.

Author : Simon Buehring

Simon Buehring is a project manager, consultant and trainer and has extensive experience within the IT industry in the UK and in Asia. He works for KnowledgeTrain which offers project management training courses in the UK and overseas. He can be contacted via the KnowledgeTrain project management training website.

knowledgetrain.co.uk

The Project Management Mindset

2008-03-17T07:45:00.000-07:00

Though there is no panacea to these inevitable outcomes, it's important to take a look back on the cornerstones that define effective and success-prone project management.

Ultimately project management like most disciplines, requires just that-discipline. This discipline of mindset far outweighs any single tool, or management fad with a catchy name. The PMBOK or The Project Management Body of Knowledge is a good reference guide to begin, refocus, or sharpen your project management mindset.

Here are some key attributes of the Project Manager mentality:

1. A solid understanding and vigilant re-education in the discipline, the science, and the are of project management and it's key knowledge and practice areas.

2. The experience and wherewithal to not attack a project with everything and the kitchen sink and instead being able to pick out the appropriate tools for improving implementation and the planning of the project.

3. Understand the dynamics of a team, and serve as the glue that holds the members together.

4. The ability to incorporate the new methodologies with the old on the fly.

5. People, People, People! A knack for understanding how to communicate effectively with your team members as it relates to project changes, overall progress, and transcribing the overall vision for the project throughout it's duration.

Overall the skills required to achieve the project manager mentality are: being flexible, possessing strong oral/written communications, the ability to think strategically and solve problems on your feet, team building and interpersonal skills, a sense of accountability for yourself and your team members, and finally the technical credibility to lead the project in question.

Author : Ryan Leibowitz

Complement the project management mindset with cutting edge tools ( http://www.managethat.com/free-project-management-software.htm ) and techniques. Also keep up with the developments of this fast paced industry at the project management journal ( http://www.managethat.com/blog ).

projectrudy@gmail.com

Simple Mistakes You Cannot Afford In Project Management!

2008-03-17T07:44:00.000-07:00

Why should you care about my viewpoints?

Good question - you don't know me - but obviously - You're confused and maybe even a bit fed up by your new assignment and it's lack of clarity...

Typical problem!

My specialty: Getting what I call "sorry ass - stranded in the ditch - projects up'n running FAST!

And by fast, I mean just that...

Fast, or instant - in like 90 days or less... And in 6 to 7 months or less, depending on size and shape - So God-Damned Blod Trimmed - So tuned up - you wouldn't even recognize it...

When my collegues couldn't make it - I usually was sent in to clean up the mess... To do the 'dirty work' - And I did. - PERIOD.

When dealing with a project. My main goal is

ALWAYS RESULTS.

I may be tough, and sometimes you'll have to be too...

Because you see... Sometimes...

Management claim they want this and that change... ..And sadly enough too... sometimes...

When you start giving it to them - they start sabotaging you

And unless you're pretty aware of that when that starts happening - and unless you take measures to do something about it - you're headed for danger... Big Danger!

And in my world...

Usually the head of the project manager is the easiest to cut off... As he or she is some kind of the modern Ninja - like a King - a Queen - however with no land...

.Left to the mercy of the warlords - the CEO's and Corporate middle management...

However... A few simple precautions will get you where you want to go, but FAST!

How?

Simply by (among a lot of things) - backing up your work, every little bit of it..

And - YES!
Definitively also make sure you back-up those seemingly small
- those insignificantly "un-important" things that you
- due to the "littleness" of them...
- never even bothered care about...

Take Care and Much Success!

Author : Arne Yri

http://www.ProjectManagementMadeEasy.com

Project Rescue Operator:: Goes In To Rescue Havoced
Projects When Others Have To Throw In The Towels...

Why Your Headline Will Make You Or Break You In Project Management!

2008-03-17T07:42:00.000-07:00

The value of a proper headline when dealing with a project (or anything else for that matter) cannot be stressed enough...
Yep! I'm talking of the headline of your email correspondence here...
It only makes the day for a project manager so much more comfortable (not to mention easier), when he/she has to find something in a hurry...
And, usually...
What else... normally... is a project other than...
"In A Hurry..."
So, if you'd just give me an appropriate headline, I'm very apt to forgive everything else, and especially typos;-) - slang or whatever have you.
The need for understandable language however... Still though, just my 2 cents...
Whenever I got e-mails of character "more or less garbled", I'd call back to make sure the importance of such a post... And, if nothing else, make the person understand the value of an appropriate - to the CASE headline!
ALSO: Whenever I had to send people e-mails myself, I'd ALWAYS follow-up through a personal visit (in person) or follow up the e-mail by a phone call...
( That is, if the message was of particular imporance or of any urgency of nature, of course. Sometimes both... - when extremely important as to avoid EVERY possibility of a misunderstanding)
AND: I cannot STRESS enough the importance of this!
Besides... In the end... I cannot even count the endless millions saved from being flushed down the sewers of project-managemen-hell - purely by following this simple... little... routine...
The most obvious reason is that you get to eliminate the fuzz and the potential B.S. INSTANTLY...
BUT...
The most important (perhaps) and not always so obvious reason?
This way there will be NO phreaking way anybody involved could ever lamely excuse themselves with the so popular and widely used:
"Ohhhh! Oh my... I didn't know that..."
Or BETTER Yet! ---> You won't Even have to put up with the even more so annoying:
"Oh... I didn't know that... I NEVER got anything like that from you..."
Just try applying this strategy yourself... Just once!;-)
It'll only take a few more (no need for more than 2 to 5 more minutes normally) minutes of your day...
.BUT, I'll promise you... These 5 more mins will more than be worth it by the end of your week...
BECAUSE: While the other guy still is scrambling around, you have eliminated just 1 more obstacle that otherwise could've set you hours, and even days and weeks back due to stupid mis-communication and needless errors...
And, just so you know, this ONE tactic alone, made it possible for me to go in - take over projects other people - more experienced - more "skilled" and longer in the trade than me - had to abandon...
.Projects gone so astray that you'd be embarrassed (and then some) to call it YOUR assignment...
Still though, among others - this one thing made it possible - not only to rescue these lemons that no-one wanted...
.but, without exception, it made it possible to do so (rescue them) - within 90 days and less.
Making them absolute killer money machines in a snap...
No matter what size - no matter how down the sewers the project ever was...
And, usually...
The project never took more than 3-4 weeks to be back on its feet...
So, the morals here must be: NEVER - EVER underestimate the power of seemingly small, and unimportant things like these...
In the end, these are the nuggets that will separate the loosers from the winners...
And, in my experience as Project Manager, you, the Project Manager live a potentially "Dangerous" life...
You are like a King/Queen, but without land of your own...
And, the head of the Project manager will always roll first, unless you have done your work - backing yourself up...
.Documenting EVERY little bit of your work, and more...
But, when the documentation is secured, and your proper means of communication are provided for... Your time as emperor is way more secure and successful...
Not to forget, but so much more fun!
Best Regards and Much Success

Author : Arne Yri

http://www.ProjectManagementMadeEasy.com
(C) Copyright 2000-2005 - Arne Yri - All Rights Reserved Worldwide
http://www.ProjectManagementMadeEasy.com/disclaimer.htm
Project Rescue Operator:: Goes In To Rescue Havoced
Projects When Others Have To Throw In The Towels...

Project Management Success with the Top 7 Best Practices

2008-03-17T07:41:00.000-07:00

Define the scope and objectives

Firstly, understand the project objectives. Suppose your boss asks you to organise a blood donor campaign, is the objective to get as much blood donated as possible? Or, is it to raise the local company profile? Deciding the real objectives will help you plan the project.

Scope defines the boundary of the project. Is the organisation of transport to take staff to the blood bank within scope? Or, should staff make their own way there? Deciding what's in or out of scope will determine the amount of work which needs performing.

Understand who the stakeholders are, what they expect to be delivered and enlist their support. Once you've defined the scope and objectives, get the stakeholders to review and agree to them.

Define the deliverables

You must define what will be delivered by the project. If your project is an advertising campaign for a new chocolate bar, then one deliverable might be the artwork for an advertisement. So, decide what tangible things will be delivered and document them in enough detail to enable someone else to produce them correctly and effectively.

Key stakeholders must review the definition of deliverables and must agree they accurately reflect what must be delivered.

Project planning

Planning requires that the project manager decides which people, resources and budget are required to complete the project.

You must define what activities are required to produce the deliverables using techniques such as Work Breakdown Structures. You must estimate the time and effort required for each activity, dependencies between activities and decide a realistic schedule to complete them. Involve the project team in estimating how long activities will take. Set milestones which indicate critical dates during the project. Write this into the project plan. Get the key stakeholders to review and agree to the plan.

Communication

Project plans are useless unless they've been communicated effectively to the project team. Every team member needs to know their responsibilities. I once worked on a project where the project manager sat in his office surrounded by huge paper schedules. The problem was, nobody on his team knew what the tasks and milestones were because he hadn't shared the plan with them. The project hit all kinds of problems with people doing activities which they deemed important rather than doing the activities assigned by the project manager.

Tracking and reporting project progress

Once your project is underway you must monitor and compare the actual progress with the planned progress. You will need progress reports from project team members. You should record variations between the actual and planned cost, schedule and scope. You should report variations to your manager and key stakeholders and take corrective actions if variations get too large.

You can adjust the plan in many ways to get the project back on track but you will always end up juggling cost, scope and schedule. If the project manager changes one of these, then one or both of the other elements will inevitably need changing. It is juggling these three elements - known as the project triangle - that typically causes a project manager the most headaches!

Change management

Stakeholders often change their mind about what must be delivered. Sometimes the business environment changes after the project starts, so assumptions made at the beginning of the project may no longer be valid. This often means the scope or deliverables of the project need changing. If a project manager accepted all changes into the project, the project would inevitably go over budget, be late and might never be completed.

By managing changes, the project manager can make decisions about whether or not to incorporate the changes immediately or in the future, or to reject them. This increases the chances of project success because the project manager controls how the changes are incorporated, can allocate resources accordingly and can plan when and how the changes are made. Not managing changes effectively is often a reason why projects fail.

Risk management

Risks are events which can adversely affect the successful outcome of the project. I've worked on projects where risks have included: staff lacking the technical skills to perform the work, hardware not being delivered on time, the control room at risk of flooding and many others. Risks will vary for each project but the main risks to a project must be identified as soon as possible. Plans must be made to avoid the risk, or, if the risk cannot be avoided, to mitigate the risk to lessen its impact if it occurs. This is known as risk management.

You don't manage all risks because there could be too many and not all risks have the same impact. So, identify all risks, estimate the likelihood of each risk occurring (1 - not likely, 2 - maybe likely, 3 - very likely). Estimate its impact on the project (1 - low, 2 - medium, 3 - high), then multiply the two numbers together to give the risk factor. High risk factors indicate the severest risks. Manage the ten with the highest risk factors. Constantly review risks and lookout for new ones since they have a habit of occurring at any moment.

Not managing risks effectively is a common reason why projects fail.

Summary

Following these best practices cannot guarantee a successful project but they will provide a better chance of success. Disregarding these best practices will almost certainly lead to project failure.

Author : Simon Buehring

Simon Buehring is a project manager, consultant and trainer. He works for KnowledgeTrain which offers Project Management training courses in the UK and overseas. Simon has extensive experience within the IT industry both in the UK and in Asia. He can be contacted via the KnowledgeTrain website at http://www.knowledgetrain.co.uk/

A Project Management Rule: Collaborate

2008-03-17T07:39:00.000-07:00

Are we using project management as a data repository for tasks or are we using it as our monitoring and control tool? Hopefully, project managers are using their project management for both.

Students who master Project Management PM learn to lead improvement initiatives that result in measurable growth in return on investment ROI, economic value added, sales growth, customer satisfaction and retention, market share, time to market, employee satisfaction, and employee motivation.

When you think of a business manager, typically, you’ll think of someone who oversees a specific functional business area—for instance, a sales team manager, or the manager of the accounting department. These folks tend to manage ongoing or frequently repeated processes such as ensuring that the sales team meets its monthly quota of cold calls to prospective clients, in the case of the sales manager.

Publishing Guidelines: You may publish my article in your newsletter, on your website or in your print publication provided you include the resource box at the end. Notification would be appreciated but is not required.

Author : S. Maurer

S. Maurer is a 53-years old college graduated IT professional, with 30 years of experience in the computer & technology business. Now is the Correspondence Courses Director of http://mba-open-university.net and http://distance-learning-mba-online-mba-program-executive-jobs.net.

Applied Software Project Management Book Review

2008-03-17T07:38:00.000-07:00

It’s not often that a software project management book comes along that is practical, easy to read and stacked full of ready to use process scripts. Andrew Stellman and Jennifer Greene have done just that with recent book Applied Software Project Management.

There are too many books about software project management or software engineering which are dry, overly complex and boring, but this book is not one of them. It was a joy to read because their style of writing is clear without being simplistic and the authors describe things in just the right amount of detail. It seems they understand their audience and set out to write in an extremely helpful and practical way. They have certainly achieved this.

Part one of the book covers tools and techniques that can be applied on projects. Project planning, estimation, scheduling, reviews, requirements, design and programming and testing each have their own chapter. Part two is about using project management effectively and has chapters on understanding change, management and leadership, managing an outsourcing project and process improvement.

A clear thread throughout the book is a description of the typical problems software project teams face – inadequate requirements, managing changes, lack of quality assurance at each stage in a project, endless testing and bug-fixing cycles, tensions and misunderstandings between the software engineers and business users. None of these problems are technical in nature, but are organisational and managerial. Stellman & Greene offer practical advice to solve these problems based upon their experience on similar projects.

Stellman & Greene certainly appear to know a lot about problems that face software teams. As early as the introduction they describe the need to overcome chronic problems and this theme is continued throughout the book. For each problem, there is always at least one proposed solution. For example, they describe a common scenario whereby senior managers do not trust the estimates of the technical team, somehow believing that the technical team are deliberately over-estimating in order to give themselves some slack time. Their proposed solution is to involve these managers in the estimation process so they can see the estimates being made in a transparent and systematic fashion. They then go on to describe in detail how to run a Wideband Delphi estimation session and provide examples of templates and documents that can be used during such sessions. They also provide a valuable process script for teams to follow.

Subsequent chapters cover planning, scheduling, reviews, requirements, design and testing. Whilst most of these chapters cover each topic in reasonable detail, the section on design is lacking in detail and provides no description about what kind of design deliverables might be produced nor any detailed description of what these design deliverables might contain. This is in contrast to the requirements chapter which contains process scripts for requirements elicitation and analysis as well as a detailed description of use cases and software requirements specifications documents.

Another nice aspect to the book is the checklists that appear after dealing with one of the main project management or software engineering topics. Checklists are important quality assurance techniques that the authors rightly point out should be used throughout software projects as a way of catching errors early. For example, if a checklist applied to the software requirements specifications catches the fact that a critical requirement is missing or ambiguous, then the error can be corrected during the analysis stage. The authors explain that by catching and fixing errors early, the cost is small compared with the cost of fixing errors found later in a project. Their emphasis on quality assurance techniques being applied throughout the project with examples of checklists to apply is therefore very practical and useful.

The authors might want to reconsider some of the examples they use. They describe the process of refactoring code in order to make it more maintainable and use an example of some Java code which they gradually refactor over several iterations. At the end of this process they say why refactoring would be applicable in situations where code is spaghetti-like. This is fine, except they use an example of very un-spaghetti-like Java code to refactor. By doing this it looks to me that they fall into a common programmers trap of code beautification where programmers spend time from the schedule iteratively improving code that works just fine in order to write the ‘perfect’ code, class or object. I’ve seen this happen on projects where there simply wasn’t the time in the schedule to allow this, and it certainly didn’t bring any additional business benefits to the stakeholders. However this is a minor gripe.

I would have liked to have seen more pages devoted to risk management. Time and again, not managing risks is cited as a reason why projects fail. The authors do describe risk management in a cursory way, yet the book would benefit from a better description of how and why risk management should be done throughout the project, not just in the early stages of project planning.

One thing I thought the book lacked was a detailed look at iterative methods. The implicit assumption throughout is that the software project should follow the waterfall method. I would disagree. There have been some important alternatives to the waterfall method which have been developed over the last 20 years most notably those based upon iterative approaches. The main downfall with the waterfall approach is it’s assumption that everything about requirements is known at the beginning of a project.

Iterative approaches on the other hand assume that requirements will change during the project either because users gain a better understanding of what they need, or because of changes to the business environment. Based upon this assumption, iterative methods are designed to better manage this changing environment. With waterfall approaches, changes in requirements often require the project to revisit earlier stages with a corresponding increase in costs and effort. The authors spend barely a page on the Rational Unified Process (RUP) and the authors should look more closely into how their practical advice and processes might be used on alternative iterative approaches to the waterfall approach.

Finally, I think the book tried to be too broad by appealing to three different groups of people. Firstly, part one is aimed at those involved in a software team (project managers, analysts, programmers and testers). Part two is aimed at consultants hired to improve project management practices and project managers who need to manage software outsourcing projects. The book would have been better had it focused solely on those involved in the software team.

The penultimate chapter dealing with managing an outsourcing project is dealt with in a cursory way almost as if the authors felt they needed to mention it because outsourcing is such a business priority these days. The final chapter dealing with process improvement is also too short to deal effectively with such a large topic. Separate books dealing solely with these issues would have been more appropriate.

Not withstanding these points, this book is an excellent guide for those people involved in software projects, both project managers and technical team members alike. They will find much they can apply directly on their own projects.

I would recommend this book to anyone who works on a software development team because the book has so much practical advice to help people improve their capability to deliver quality software. Come to think of it, I would also recommend it to senior managers of companies who have a negative view of their own software development teams. Perhaps then senior managers might understand why committing resources to process improvement is one of the best investments they can make.

Author: Simon Buehring

Planning user documentation - a guide for software project managers- Part 1

2008-03-17T07:33:00.000-07:00

Introduction

A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–2000 Edition is the main sourcebook in the project management field. Whilst it covers Project Communications Management, it doesn't extend to user documentation.

This article seeks to provide guidance for project managers as to how the user documentation process fits in with the overall project planning. It examines:

the traditional way documentation is approached and how it impinges on project planning
the effects of making changes to this traditional approach.

What do we mean by documentation?

When talking about documentation for a software application, most people think of the traditional paper-based or online manual. In this article, we will be looking at ways of taking this traditional approach forward. The term 'user assistance' then becomes more useful, implying 'anything that makes the user's life a bit easier'. More on this later…

Your project plan

A typical plan for a software project might look like this:

A Traditional documentation project plan

A traditional documentation project comprises the following stages:

The vertical grey bars on the above diagram represent reviews of the work done. These bars are not to scale. Reviewing can take a lot longer than you might think and must be done by somebody with expert knowledge of the software.

Prototype

The prototype comprises a structured set of empty topics (pages of information) with a prototype look-and-feel. For each different type of topic, one is populated with content as a sample. The review is to determine completeness and suitability of the structure together with suitability of the look-and-feel, writing style and writing conventions.

First Draft

During the first draft stage, the author writes the content for all the topics. This is the longest stage and takes the longest to review. The review is to check for technical accuracy of all the content.

Second Draft

The second draft stage is for the author to make the necessary changes, reported from the first draft review. The review is to confirm that this has been done and to request any minor tweaks still outstanding.

Final Draft

The final stage is to follow up on the minor changes picked up at second draft review. The result is the final deliverable.

Author : Carol Johnston, Technical Director

Cherryleaf Ltd.

Planning user documentation - a guide for software project managers- Part 2

2008-03-17T07:31:00.000-07:00

So where does the documentation fit in with my project plan?

Traditionally, the documentation comes in towards the end of the testing stage of your project. The software is more or less stable and you're close to launch. Having seen the stages involved in the documentation, you may be thinking that it's a lot to cram into this stage. You'd be right! This is why many project managers see documentation as that necessary nuisance that takes up valuable manpower to create and review just when deadlines are looming.

So it is also vital to consider the effects of the documentation at the initial planning stage.

In this first stage of your project, your planning will include such things as:

§ Timescales and resources

§ Roles and responsibilities

Timescales and Resources

When thinking about timescales, don't forget the time required for the documentation! It may seem obvious, but effective documentation takes time to develop. As seen in the typical documentation project plan above, the elapsed time can be much longer than just the writing time due to the review process.

Depending on the scale and complexity of your software, you may have to consider splitting the documentation between different authors. Authors working in parallel can speed up the process, but be warned – depending on the tool(s) used to create the documentation together with the associated workflow this may not be possible. In addition, there is the extra issue of keeping the documentation consistent across the authoring team.

As well as providing the writing resources, it is just as important to provide adequate resources for the reviewing and a documentation project manager to coordinate writers and reviewers. All this must be factored into the cost.

With so much to do in the testing stage of your project plan, the inclusion of the documentation at this stage and the drain on expert staff for reviewing presents a real project risk if not properly planned and resourced.

Roles and Responsibilities

Who should write the documentation?

If your organisation has a specialist documentation department then your solution is simple.

So what are your options if this is not the case?

The programmers themselves

Seems logical. They certainly know the product inside out. But beware. The programmers are experts in programming – not necessarily in communicating! They may well assume a level of knowledge that the end-user does not have. Not only that but their enthusiasm for their creation often gives them an understandable tendency to explain every last technical feature in detail – focussing on product functionality rather than answering users' questions.

A contracted technical author

This is often a good solution, though it very much depends on the rest of your project plan. In the build stage of your project plan, you may be setting aside long stretches of time on the coding of the software between tests. Unless there are other projects to work on, a technical author can be left idle and compromise your budget.

Outsourcing

Contracting an external organisation to project manage and develop your documentation means that you will only get charged for the days spent managing and writing. This solves the problem of idle time, but does have a couple of disadvantages. One is that the author spends most of the actual writing time off-site so direct communication may be more difficult. The other disadvantage is that it may not be possible to guarantee that one particular author will be available if timetables and deadlines change.

Who should review my documentation?

You may want or need more than one reviewer. As already mentioned above, all the documentation at every stage must be reviewed by at least one expert in the software. This ensures fitness for purpose and technical accuracy. In addition, it is often useful to get other relevant people to review parts of the documentation. One example is if you have access to some helpful end users. Their comments can be very valuable. Another example is if there is to be a training programme for the software. The training staff can provide useful feedback.

Who should manage my documentation?

As stated previously, the documentation project manager is necessary to co-ordinate the writing and the reviewing process. Unless your programmers are writing your documentation, many questions will arise on the author's part about the details of how the software is to be used. So part of the project manager's role includes co-ordinating these questions and their answers between the author and the programmers.

If you are outsourcing, the external company manages the delivery of the drafts, the receipt of review points and the author's questions for the programmers. However, there should still be a person named as the documentation project manager in your organisation to provide a single point of contact for the external document project manager. Without this role, review points get fed to the external company in dribs and drabs and sometimes contradict one another.

Author : Carol Johnston, Technical Director

Cherryleaf Ltd.

Planning user documentation - a guide for software project managers - Part 3

2008-03-17T07:28:00.000-07:00

Spreading the authoring work more evenly

The traditional close-to-launch timing of the documentation presents, as mentioned already, a project risk. To reduce the amount of time and resource required at this busy time, there are a number of tasks that your technical author can do earlier on in the project to reduce the project risk.

Look and feel of the Help system

These days, authoring tools for technical writers are making it possible to create Help systems with a customised look-and-feel. Software houses are now getting more interested in their Help systems looking better than the rather grey-looking standard Help viewers (for example WinHelp and HTML Help) and more in line with the software itself. Creating a customised look-and-feel takes time. But this is one of tasks your technical author can be doing in the design stage, as soon as the software look-and-feel is agreed.

Structuring the Help system

Depending on the complexity of the software, it may be possible for the technical author to sketch out a rough structure for the topics in the Help system after the design stage. This would be a flexible work-in-progress structure, but would at least set out a draft of the types of information to be documented.

Conceptual topics

Generally speaking, the majority of Help topics in a Help system are procedural. They tell the user how to do something by giving detailed step-by-step instructions on using the interface so, in the main, are best left until the software is more or less stable. However, there will also be some information for the user that is of a conceptual nature. It may be possible for your author to document some such concepts during and after the design stage.

Summary of where your documentation fits into your project plan

Getting more value from your technical author

Specifications and design stage

It may not be something you have considered, but since good technical authors have expertise in designing information, they can also provide useful input at the specifications and design stage. Getting your technical author on board at this stage can help make the user interface more usable. This reduces your technical support costs and may reduce the time it takes to document the software. It may be something as simple as labelling or ordering the fields on the dialogs in a more helpful way. Moreover, authors with experience in writing for screens will know what sorts of layouts will and won't work. They can provide valuable input for decisions on the structuring and the look-and-feel of the interface. And remember that they are very much user-focussed – providing balance to what may be an over-enthusiastic graphics design team! You can think of the technical author as the representative of your average user as the specifications are decided and the design progresses.

Embedded Help

If your technical author is contributing expertise during the specification and design stage of the project, it may well be that the traditional paper manual/online Help 'documentation', created at the very end, is reduced in scope or even unnecessary. In other words the 'necessary nuisance that takes up valuable manpower to create and review just when deadlines are looming' is all but eliminated. The user interface can contain its own 'user assistance'. This kind of approach is known as Embedded Help. Exactly how and where the assistance is provided is part of the specification and design process. For example, one successful technique is to have a dedicated (but shrinkable) part of the interface for displaying context-sensitive assistance.

Build stage

If present at all relevant meetings, the number of questions your technical author will have for the programmers when writing the Help content will be reduced, saving precious time near the end of the project.

Testing stage

If you are planning to perform usability testing, your technical author can participate in designing and giving the tests and in interpreting the results.

Post rollout

If you are outsourcing, the external organisation may provide a service for logging and collating user feedback, reporting it to you and updating the Help where appropriate.

Summary

Providing online assistance for software is important since it can reduce costs of technical support and make life easier for your users. However, documenting software is not a trivial task. It requires time and resources for writing and reviewing that must be included in the overall project plan.

The documentation work is traditionally implemented after the software is reasonably stable – during the testing stage. However, getting your author on board earlier spreads the work more evenly, reducing project risk. Moreover, including your author in design decisions and usability testing can improve the user interface.

Author : Carol Johnston, Technical Director

Cherryleaf Ltd.

Project Management Best Practices: Key Processes and Common Sense

2008-03-17T07:20:00.000-07:00

Giga Position

Organizations continue to look for the key to unlocking the mystery of project management (PM) best practices, but the steps that go into successful project management are not mysterious at all — they are standard procedures that, if executed, will improve a project’s chances of success. The key word here is “if.” Projects fail because of poor planning and fuzzy requirements that cause a chain reaction of poor productivity. Regardless of size, good projects benefit from careful planning and active management. Follow the 20/80 theory: Increase your planning process by 20 percent, and you will reap 80 percent growth in productivity.

Giga expects to see an annual 15 percent per year increase in formal project management practices during the next five years. Companies formalizing these practices will have to develop and actively use management procedures, including planning and communication, to facilitate project delivery.

Recommendations

Build a best-practice library of methods that have worked in previous projects. Keep it modular, so that procedures can be tailored for a specific project based on size, complexity, team structure, etc. The library is a living repository that grows with each completed project. Requirements management tools are excellent repositories for artifact information that can be reused for efficiency, as are project management tools that store completed project plans that can be reproduced as templates. As projects are completed, perform a postmortem to update or change procedures for continual improvement.

For organizations that do not have accessible historical project data and want to purchase developed methodology, consider a training program with certified training consultants that offers not only core methodology training, but also key areas, such as cost management, assessments and requirements management. Another alternative is to contract a specific project with a consulting organization that can deliver proven project plans and will transfer knowledge and practices.

Refer to standard industry reference material as a guide for building internal practices; the Project Management Institute’s (PMI) Body of Knowledge (PMBOK) provides detailed information about core professional project management procedures. ISO 9000 and the Capability Maturity Model (CMM) are also excellent sources for best practice information. While each of these standards may be too involved for your organization’s requirements, there may be individual procedures you can use that will improve weak areas in current practices.

Proof/Notes

We Don’t Have the Time to Do It Right, but We Have the Time to Do It Over

Despite the claim that project management is widely accepted as common practice, the reality is that less than half of the companies claiming to have integrated project management practices have standard procedures extending beyond strategic projects (see IdeaByte, Enterprise Project Management Tools: Is Your Company Ready? Margo Visitacion). Performance is ad hoc and changes with each new project. Without a standard foundation for execution, projects fall down when there are no standard procedures. Failure to gather and maintain adequate requirements causes project teams to have to rearrange delivery dates and to miss deadlines. Organizational pressures, such as lean resource availability, cause continual resource constraints, forcing project managers to scramble to find adequate coverage. When the pressure to deliver becomes too great, common sense often goes out the window, and then crucial steps, like testing, are skipped. The end result is shoddy, and the rework required to repair the damage is far more expensive than if it were caught in the planning stages.

All projects come under fire, but in an uncertain economy, increased pressures to derive optimal value emphasize the need to ably deliver projects. Reduced budgets and leaner staff do not equal reduced expectations; companies with smaller staffs and/or increased reliance on outsourcing are realizing that strong process is the key to better application development and avoiding expensive rework. Even in accelerated life cycles, planning and management best practices can be exercised. In traditional projects, planning was an exhaustive process; in accelerated cycles, successful planning concentrates on drawing boundaries to create a prioritized set of deliverables that are released in iterative phases. Process is not about reinventing the wheel, but finding what has worked in the past and applying it to the present, using strong communication to deliver and manage these processes and paring away anything that diverts the team from project goals. The ultimate challenge for project management is to find a repeatable process and communicate it clearly so that multiple levels within an organization accept and support the benefits.

The key to best practices in project management is no mystery; it lies in the execution. Projects benefit from repeatable standard functions, regardless of size (see figure below).

Project Management Best Practices

The best practices of project management have been written about in dozens of formats. The PMBOK breaks it into 37 key process areas; most projects are finished before the project manager actively understands what those areas are. From an educational standpoint, the PMBOK provides a manager with an excellent explanation of why each area is important; unfortunately, current life cycles do not actively support every detail mentioned in PMBOK. Flexibility is vital here. In order to plan and execute effectively, break it down into small repeatable phases that can be arranged to best suit the project’s goals. For example, portions requirements management will be practiced throughout the life of the project in status meetings and in audit processes. Take the information gathered as part of requirements management (RM) as a guide for measurement to keep project scope in alignment. There are many things you can do to manage projects;

however, the following are practices that you must perform in order to execute a successful project:

Scope:

§ Know if it “cuts the mustard”: Before undertaking any project, evidence must exist to support its value. Perform a feasibility study to gauge market potential, enterprise risk/benefit and technological impact before any activities are started (see IdeaByte, What to Include in a Feasibility Study, Margo Visitacion).

§ Follow a structured initiation process: Gaining executive understanding and commitment before undertaking a project, especially one that carries some risk for IT, prevents political jockeying over priorities and resource commitment. Make sure that the project has a designated business champion, and gather the necessary business and technological criteria to justify the project to continue adequate executive support during the life cycle.

Planning:

§ Plan: Comprehensive planning is critical, even with short development cycles. Make project goals attainable by prioritizing deliverables to keep a team tightly focused on specific issues. From there, involve the team, stakeholders and sponsors in closely managed sessions to discuss each objective and clearly explain risks and benefits to understand exposures and the dangers to the project. Doing this promotes a unified front, because everyone understands how the project is affected by unnecessary changes, especially if it is understood that more features will follow shortly (see IdeaByte, Effective Risk Measurement in IT Projects, Jon Erickson).

§ Maintain realism in planning: Determine short-term “must haves” (e.g., one to three months) and long-term goals (e.g., one to three years). In order to keep to delivery dates, it is often necessary to deliver a streamlined application or site with enhancements coming in regular scheduled intervals. Open communication at this point is critical to maintain expectations. Meet weekly with stakeholders to keep scope creep to a minimum.

§ Assess requirements: Perform stakeholder interviews to ascertain the business and usability objectives for the project. Hold collective review sessions and prototyping whenever possible to keep the project team focused on the correct path and manage end-user expectations. Automate the requirements management process whenever possible to provide a central location for audit trails and status management.

§ Don’t overload milestones: Keep the milestones actionable, and keep them close together (ideally, no more than three weeks apart); however, in a project of less than three months in duration, the spacing can drop to 1½ weeks. This is critical if you are opting for short-term deliverables within a compressed life cycle. Closely spaced milestones provide opportunity for faster recovery if the project starts to stray.

§ Publicize your plans: Distribute regular and relevant status information in the most accessible way possible, for example, e-mail, intranet project pages or an enterprise project management tool. The more people who are intimately familiar with project requirements and action plans, the less cause there is for a misstep. Broad access increases the chances of catching a potential problem that a project manager may have missed.

§ Delegate: A project manager cannot, and should not, do it all. Use the team approach whenever possible for planning and execution, guided by the project lead. For example, the system architect and senior programmer manage the architectural and system design phases of the project and report to the project manager, who focuses on administrative and coordination activities.

§ Manage vendors: This has two meanings. During the planning phase, if standard tools for communication and execution are not in place, it is critical for the team to implement them. This is especially true if the team is outsourced or distributed. A single location for critical documentation and communication is essential. For project execution, designate a single source, whether it is the project manager or a lead technical person, to be the single point of contact for any vendor issues. Clarify expectations for reporting, issue management and deliverables and penalties for not meeting those expectations. Get these agreements in writing.

Execution/Control:

§ Delegate, part two: The small-team approach allows a project team to remain flexible and not get bogged down in the minutiae. Even if a project is large in scale, the small team works effectively. Empower project or team leaders to manage tasks within their areas of expertise and work closely to keep communication open. Keep everyone on task by meeting formally on a weekly basis to review and measure against milestones, but meet daily on an informal basis to head off possible problems as quickly as possible.

§ Automate whenever possible: Make automation as accessible as possible. Use requirements management tools, such as Telelogic Doors or Borland’s Caliber RM, to track changes in scope or keep additional critical information centrally stored. Project management tools, from vendors such as Project Central, eLabor.com and Business Engine, allow team members to track time and issues that keep project managers and team members informed of progress and assist in avoiding miscommunications regarding objectives.

§ Collaborate, collaborate, collaborate: Team members perform much more effectively if they are in active communication with each other so that each dependency is clearly understood and managed. Hold weekly information sessions with the team to discuss issues, and collectively figure out correction strategies. If the team is scattered, use collaborative tools such as Webex, Placeware or Centra (see Planning Assumption, Comparing Team Collaboration Vendors on Their Functionality, Erica Rugullies) to hold meetings and share information. The method is not as important as the action itself. Keep everyone informed.

§ Use audits: To assess the health of the project, hold biweekly audit sessions, and check the status and progress of the project. Issues discussed during an audit are actual progress vs. work and cost estimates, requirements measurement for scope control and overall quality measurements in productivity. The actual audit process is very flexible; using the project charter as a guide, the team prepares criteria that measure the entire project, and then uses subsets of those criteria for assessment with each milestone. Short life-cycle projects can still benefit from audit sessions that ensure that precious time is not wasted. Keep them short and to the point, and refrain from personalization. Keep the focus on the project goals (see IdeaByte, Auditing Projects — The Long and Short of It, Margo Visitacion).

§ Measure productivity: You can’t improve if you don’t measure. Develop standard criteria for measurement, such as meeting deliverables, defect detection, resource utilization and rework, to find out where you can optimize or where you need to devote extra attention (see Planning Assumption, Update: Selecting Metrics and Using Them Effectively, Margo Visitacion).

§ Practice change control: Regardless of project size, if change control is not practiced, the project won’t meet deliverables and will miss delivery dates. Use software configuration management or requirements management tools to automate and manage the change process. Establish a chain of command for approving any scope change for the project. Formality depends on life cycle, but make sure that at least one business and technical lead is consulted for every change to estimate risk and duration of the changes (see IdeaByte, There’s More to Change Management Than Change Control, Margo Visitacion).

§ Test: It is critical to test early and often to ensure that the project is meeting deliverables and is production-ready. Hold walkthroughs, for example, end-user style demonstrations, peer-to-peer code inspections, information inspections, etc., at various stages of the project to ensure that the quality is built-in and that certification time is reduced. Allot time for user acceptance testing and beta testing whenever possible to minimize postproduction problems. At a minimum, testing should account for 15 percent of the project. If the technology is new or there are large amounts of system integration, plan for a minimum of 30 percent test time over the life of the project.

§ Design concise implementation procedures: Develop a step-by-step implementation plan that covers production test procedures, installation requirements as well as a contingency plan for problem management that includes back-out procedures and production support steps. Accompanying documentation must include release information: known problems, a high-level test plan (for production test prior to implementation) and contact information (see IdeaByte, Standardize Internal Software Implementations for Efficiency and Control, Margo Visitacion).

Closure:

§ Conduct a postmortem: This is the time to hash out any issues that will improve production support and improve process for the next project. Be sure to collect all project issues that caused any delays or restructuring of project focus, implementation issues and “morning after” support problems. Like audits and walkthroughs, these are not forums for personal criticism, but are used to analyze procedures for improvement.

§ Check temperature: Assess project success at several intervals after implementation to measure how well the project met expectations. This important metric delivers the foundation for future project growth. For example, if there are high levels of production support or rework, check the requirements and design processes; chances are, there was something critical missed during this phase where easy corrections were possible.

Alternative View

Adopting some practices for larger projects is suitable, but is too time consuming and inefficient for smaller projects. Borrowing from standard practices is fine, but project managers should not be tied to a rigid set of practices for unpredictable projects. Procedures should be tailored to the project.

Findings

If an organization has experience in developing various types of projects (but has little to no centralized project management), it should have a repository of organizational history to serve as a starting place to design procedures. Analyze current project practices, and perform a gap analysis between successful and challenged projects. Procedures that worked for previous projects may work for current procedures. Even in shorter development cycles, the process works by breaking down a successful method into its core objective, e.g., requirements management worked in previous projects because of strong stakeholder interviews.

Author : Margo Visitacion

References :

Related Giga Research

Planning Assumptions

Giga’s Framework for Project Selection and Prioritization, Margo Visitacion

Designing an Enterprise Project Management to Improve Organizational Project Management Efficiency, Margo Visitacion

Comparing Team Collaboration Vendors on Their Functionality, Erica Rugullies

Update: Selecting Metrics and Using Them Effectively, Margo Visitacion

IdeaBytes

What to Include in a Feasibility Study, Margo Visitacion

Effective Risk Measurement in IT Projects, Jon Erickson

Auditing Projects — The Long and Short of It, Margo Visitacion

Code Reviews — Applications and Benefits, Margo Visitacion

Standardizing Internal Implementations for Efficiency and Control, Margo Visitacion

There’s More to Change Management Than Change Control, Margo Visitacion

Relevant Links and Other Sources

The Project Management Institute

Giga Information Group, Inc.

Is project management all administration?

2008-03-13T00:57:00.000-07:00

By Tom Mochal, TechRepublic

Tuesday, January 6 2004 11:30 AM

Question

I'm thinking about switching my focus to project management. The concern I have is that it seems that most project managers I know spend the bulk of their time dealing with administrative paperwork. I'm sure there is more to the job than that, but how much of the role is administrative?

Answer

I know a lot of project managers would agree with your comment that it seems like administrative work takes up a lot of their time. However, to be honest, administrative work is in the eye of the beholder, so to speak. What one person sees as dull administrative work might be a vital part of controlling the project to another person.

Defining what makes up administrative work can be a tricky proposition. Some project managers think that anytime a document is involved, it is an administrative task. Some might go as far as to say that anything that requires writing (or typing) is administrative. But, generally, administrative work should be defined more by its relationship to the project rather than the type of work it is.

For example, if your organization requires some type of report that is not project-focused, you might say that it is administrative. You may also participate in other non-project-related activities, such as interviewing new employees, filling out surveys, and responding to management requests for information, and that work might also be considered administrative. Still, there are jobs that fall into the project manager's domain that have every appearance of being administrative work, but aren't.

A quick definition of project management. This is probably overkill, but it might help to quickly define the project manager's job. In general, the project manager is responsible for the overall success of the project. He or she leads the team through a definition and planning phase and then monitors and controls the project until it successfully concludes. This would include managing scope, issues, quality, and so on. Notice that performing general administrative work is not a part of that simple definition.

In addition, the project team may or may not report functionally to the project manager. The project team members may report to a different manager for things like performance reviews, while reporting to the project manager for their workload. In other companies, the functional reporting relationship goes directly to the project manager.

However, in either case, the project manager must also perform people-management responsibilities. This includes soft skills like listening, providing feedback, being empathetic, providing leadership, and so on.

It's all part of the job as I mentioned earlier, many jobs that are part of the project management landscape feature elements of administrative work, but they are too critical to the project to be correctly called anything other than the project manager's job. Here are a few examples of this type of project management work:

* Handling status reporting: I think you can tell a lot about the mind-set of a project manager based on how he or she looks at status reporting. Many project managers think that status reporting falls under administrative work. I think that status reporting falls directly under the jurisdiction of a project manager in order to proactively communicate status. When I am in a project management role, I plan out the best way to deliver status updates to my stakeholders as a part of a communication plan. To me, this is not administrative work. This is a fundamental part of my project management responsibilities.

* Updating the work plan: I have mentored project managers who hated to update a work plan and thought that work plans were an administrative burden. To me, updating the work plan is one of the core responsibilities of the project manager.

* Completing a project definition: Again, many project managers just want to get going and start the work. To them, planning is an afterthought and not something that should hold up a project. To me, if the project manager views the definition process as administrative work, it implies a certain lack of project management maturity. There is always a legitimate question as to how much planning is required, but there never should be a question about doing it or not doing it.

* Updating project logs and forms: Many projects have forms that are used to request scope changes, or perhaps the project manager keeps track of issues on an issues log.

* Conducting performance reviews: If you have project team members that report to you, you undoubtedly have some paperwork affiliated with the performance review process. This has a direct tie to your people-management role.

The final word

I hope this response gives you some more insight into the project management role. Much of what might appear to be administrative work is really the direct input or output related to project management or people management. Project managers can master this aspect of their job and relegate it to a smaller percentage of their time. However, if you have an aversion to this type of work, project management may not be right for you.

Author : Tom Mochal is president of TenStep, Inc

Software Engineering Project Management 20 Years Later

2008-03-13T00:52:00.000-07:00

Author :

§ Arthur B. Pyster, Science Applications International Corporation

§ Richard H. Thayer, Software Management Training LLC

A little more than 20 years ago, we assembled several papers on software engineering project management for the January 1984 edition of IEEE Transactions on Software Engineering. Those papers portrayed the state of the practice in SEPM and looked into its future. We decided to revisit SEPM and assemble another set of articles that reflect how it has advanced over the past 20 years and offer a fresh prediction of what lies ahead.

Where were we 20 years ago?

In 1984, as some of you will recall, there was no Capability Maturity Model (first described in a 1987 technical report by Watts Humphrey) or ISO 9001 (approved in 1987). The Project Management Institute was just offering its certification program for the first time. The US Department of Defense was the largest creator of software technology, as demonstrated by its invention of the Ada programming language, sponsorship of the Software Technology for Adaptable, Reliable Systems program, and the formation of the Software Engineering Institute. Strong, rigorous configuration management, quality assurance, requirements management, formal reviews, earned-value management, and other software processes that are commonplace today were then quite unusual. Three years earlier, Barry Boehm had just defined the whole field of software engineering economics with the publication of his landmark book of the same name introducing COCOMO, the Constructive Cost Model for software.

The papers in that 1984 special issue were

§ Software Configuration Management by Ed Bersoff,

§ Software Engineering Economics by Barry Boehm,

§ Software Engineering Project Standards by Martha Branstad and Patricia Powell,

§ Software Project Management in a Small Project Environment by Bill Bryant and Stan Siegal,

§ Project Management Planning by Jack Cooper,

§ Earned Value Technique by Norm Howes,

§ In-house Training of Software Engineers by Jim McGill,

§ Software Quality Assurance by Fletcher Buckley and Bob Poston,

§ Software Engineering Projects by Walt Scacchi, and

§ Reviews, Walkthrus, and Inspections by Gerald Weinberg and Daniel Freedman.

Several of those papers stand out even today. Bersoff’s and Boehm’s articles were bothseminal. Bersoff’s article is still among the best at describing the ins and outs of software configuration management, which remains one of SEPM’s most valuable tools. COCOMO retains wide popularity and usefulness, having spawned several updates, including Boehm’s COCOMO II.

Branstad and Powell described the state of the practice in software engineering standards in 1984. They listed standards by the IEEE, the US Department of Defense, and some European software developers. At that time, the IEEE had developed five software engineering standards, so it was the most prolific standards developer, closely followed by the DoD.

Since that time, the DoD has gotten out of the software standards business, the IEEE has developed approximately 36 standards, and the ISO (International Organization for Standardization) and the IEC (International Electrotechnical Commission) standard development groups have grown much more prolific.

Howes’ paper on earned value called attention to another valuable management tool, which has become extremely popular in the last few years across the US government with strong encouragement from the White House Office of Management and Budget. ANSI Standard 748 for earned-value management, approved in 1998, elaborates on the process that is partially automated by several popular commercial tools. US government contracts now routinely require companies to use an ANSI compliant earned-value management system.

Weinberg and Freedman wrote about three types of software project review:

§ acquirer-supplier review—a management review used to determine the status of a large software development project;

§ inspection—a formal peer review used to find errors in a software product; and

§ walkthrough—an informal peer review used to find errors in a software product.

Inspections have proven to be one of the most valuable tools (if not the most valuable) for finding a software product’s bugs. The US’s NASA Space Shuttle program uses this technique extensively.

Where are we now?

Of course, many of the practices called out in the 1984 issue are now much more well known. A catalyst for their spread has been the popular CMM and its derivative, the Capability Maturity Model Integration (CMMI).

But what was their effect on organizations’ ability to deliver projects on time, within cost, and with required performance? Unfortunately, the 1995 Standish Group CHAOS Report and the more recent update in 2004 show quite clearly that the more things change, the more they stay the same. Despite the myriad books, training, consultants, and tools that enable best practice, most projects still fail. According to the Standish Group, fewer than 30 percent of information technology projects succeed, nearly 20 percent are canceled before completion, and the remaining 50 percent are challenged—that is, they’re seriously late, over budget, or lacking expected features.

How is it possible that the best practices called out in 1984 aren’t producing the desired results? We believe there are two primary reasons. First, even though development organizations commonly follow many of these practices to some degree, most still don’t perform them rigorously. Most software development organizations are still Maturity Level 1 with respect to either the CMM for Software or the CMMI.

Second, competitive pressures and national imperatives keep driving a stunning growth in projects’ size, speed, and complexity. Projects today produce two and three orders of magnitude more code than their counterparts did 20 years ago. As an example, Microsoft Windows didn’t even appear until late 1985 and was absolutely primitive by today’s standards. (Remember DOS?) Projects that would have taken years to complete in 1984 are now being done in months or even weeks. Organizational leaders keep pushing what they demand from projects—and project managers—to the point where failure remains common.

What has really changed in the last 20 years that the earlier special issue on SEPM didn’t address? Among the most fundamental changes have been these:

§ The creation and broad adoption of SEPMrelated standards, especially the prominence of ISO 9001 and the CMM in both their original and latest incarnations. For example, the CMM demands rigorous configuration management, quality assurance, peer reviews, and other techniques that the 1984 special issue highlighted.

§ The backlash against the determinism of the waterfall and big-bang approaches to development and against the CMM’s planning and document focus. Spiral development, incremental delivery, and agile methods are among the results of that backlash.

§ The credentialing of project managers as reflected in the Project Management Institute’s more than 150,000 members and the newly emerging credential standards for both systems engineers (through the International Council on Systems Engineering) and software engineers (through the IEEE).

§ The ability to manage projects with a highly distributed workforce through collaboration technology made possible by the Internet and the World Wide Web.

§ The reality of product lines as a well-defined software engineering discipline.

In this issue

The articles in the current special issue address aspects of how these sea changes affect SEPM.

Suzanne Garcia writes about standardization as an adoption enabler for project management practice. In the context of half a dozen standards, she analyzes where standards have helped, what makes a good standard, and the challenges that organizations face when adopting standards. Adopting the wrong standard or too many standards, even if it’s trendy to do so, can be detrimental to an organization. Adopting a standard that requires an organization to shift its culture too rapidly will likely fail. Only in sustained crisis will people change rapidly and stay changed.

Agile methods are a direct reaction to the plan-driven software development approach the CMM articulates. Reconciling the flexibility of agile methods with the necessary rigor on larger projects remains a challenge. Barry Boehm and Richard Turner analyze that challenge and suggest ways to address it. For example, they propose developing architectures that support compartmentalization of agile and traditional teams. That way, the right techniques can be locally applied to the advantage of the project as a whole.

Walker Royce’s analysis of successful software management style is perhaps the most controversial article in this issue. It’s also a reaction to the plan-driven approach to software development. Royce draws an analogy between creating a movie and creating software. Both, he asserts, have lots of scrap, but he doesn’t see that as a failure—it’s an inherent part of the creative process. Trying too hard to minimize mistakes along the way stifles needed creativity and flexibility. Both movie making and software development are successful because of a “steering leadership style rather than the detailed plan-and-track leadership style encouraged by conventional wisdom.” He also argues that required process rigor is fluid. The correct answer is not either agility or rigorous planning, but each emphasized at the proper point in the development process. According to Royce, planning should generally be less detailed and rigorous at the beginning of a project and increase over time when more is known on which to base detailed plans.

C. Venugopal drives one of Royce’s ideas to an extreme. A software project that’s late or over budget or that doesn’t meet its performance requirements is normally considered a failure. Venugopal argues that the reason for failure is often trying to crowd too much into early releases. He proposes limiting early requirements to a single or small subset of goals. Most often, he argues, even a large, complex system has a compact primary goal. It’s another form of the 80-20 rule; that is, that 20 percent of the functionality provides 80 percent of a system’s value. Initially, he argues, strive only for the 20 percent most critical functionality to achieve early success.

Distributed project management has become the norm in today’s large projects. Despite every project manager’s desire to have the entire team colocated, for all but the smallest projects this almost never happens. Teams are scattered across multiple companies, time zones, cultures, and continents. The Internet and World Wide Web have given project managers a technology base of Web conferences, whiteboards, instant messaging, and a host of other tools for a distributed team to work together both synchronously and asynchronously. Nevertheless, enormous process and cultural challenges remain. Kenneth E. Nidiffer and Dana Dolan look at how project management is altered in such a world and provide a list of potential enablers and current constraints on those enablers.

The article by Paul C. Clements, Lawrence G. Jones, John D. McGregor, and Linda M. Northrop describes software product lines, an idea that has been around for two decades but which is becoming a mainstream way of building software, whether for automobiles, telephones, or a myriad of other domains. Successfully building product lines requires different management approaches because there are really two different types of projects—those creating core reusable assets, and those applying them. Getting the right mix of people in those different types of projects, keeping reusable assets refreshed, and understanding how to manage risk are substantial challenges.

Finally, J. Fernando Naveda and Stephen B. Seidman write about the emerging credentialing of software engineers, following the patterns set by the Project Management Institute and the International Council on Systems Engineering for their constituencies. The notion of credentialing software engineers has been controversial over the years, with many disagreeing that the field was mature enough to test for the correct foundational knowledge. The emergence of an IEEE credentialing program is a major milestone in software engineering’s maturation.

Twenty years is a very long time in the computing field. Yet, SEPM’s progress has been agonizingly slow in many ways, probably because it’s driven more by human behavior than by technology. People change their behavior much more slowly than technology advances. However, progress is notable in some areas, and this issue’s articles illustrate some of the best advances in the field.

Arthur B. Pyster is senior vice president and director of systems engineering and integration at Science Applications International Corporation. Prior to that, during part of the time he worked on this issue, he was the deputy chief information officer of the US Federal Aviation Administration. His research interests include systems engineering and software processes. Among his accomplishments, he oversaw the development and application of three CMMs, was
the chief architect of the first integrated digital environment at TRW, created and operated the information systems security program at the Federal Aviation Administration, and wrote Compiler Design and Construction. He is a senior member of the IEEE. He received his PhD in computer and information sciences from Ohio State University.

Richard H. Thayer is a consultant and lecturer in software engineering and project management and an emeritus professor of software engineering at California State University, Sacramento. He is also a Certified Software Development Professional and a registered professional engineer; he edited the CSDP Resource Guide and developed the CSDP Exam Preparation Course. He is a Fellow of the IEEE and a member of the IEEE Computer Society Golden Core and the IEEE Software Engineering Standards Committee. He is a principal author of two IEEE standards, including the Standard for Software Project Management Plans. He received his PhD in electrical engineering from the University of California, Santa Barbara.

List of Project Management Software

2008-03-13T00:43:00.000-07:00

The Software Network has enlisted web base project management software, online project management software, free project management software available to try for certain period, with free software demo to download or free personalized demo.

onProject, Inc.
onProject - Web-Based Project Management Software

onProject, Inc. offers a monthly rental service for those companies that want powerful and flexible collaborative project management functionality without the cost or efforts of ownership. Thousands of our customers have chosen this method of deployment because of its lower initial cost and immediate access and setup via the Internet. We provide the hardware, software and support. You supply the project or processes.

AlNik Solutions
PMPlan - Project Management Software

PMPlan is a powerful set of tools for interactive project planning and resource management. It enables the project manager to plan and report performance, addressing the value earned of project activities against a baseline plan. PMPLANs tools offer enhanced resource management, and detail control of project budgeting and tracking, including accurate variance analysis and earned value reporting methodologies.

The Mirus Group
CMP Forms

CMP Forms is a software solution to document, communicate, and execute change management programs and projects. It is available in both Windows and Mac versions. To learn more about the software and to order go to www.changemanagementsuccess.com The forms included in the software have been developed and used for over twelve years in managing change programs and projects.

Softalot LLC
Softalot Team Manager

Web based Project Management and Collaboration. Shared Gantt Chart, Tasks, Grouping, Roll-ups, Action Items, Calendar, Today's Summary, Plan Changes, Status Reports, File Manager, Meeting Minutes, Inbox, BBS, Contacts with Notes, and MS Excel Reports

IC Soft, Inc.
icTracker: Task Management and Project Management Software

icTracker is a fully web-based productivity enhancement software for project management, task management, document management, and bug tracking

eTech SolutionCorp
eTech Project Management and Time Sheet Solutions for the Web

eTech SolutionCorp delivers software solutions for project management, time & expense tracking, web time sheets and client billing.

Corecon Technologies, Inc.
Corecon - Setting Standards in Construction Software

When making decisions about technology solutions, one objective you should try to keep in mind is to see how well the software integrates estimating and project management. At Corecon Technologies, we have led an effort to make the job of transferring information from the estimating system into the project-management system easier, more efficient, and more foolproof.

Xpress Software Inc
Advanced Time Reports: Personal Edition

Advanced Time Reports is an intuitive time tracking & project management solution that will help you increase your billable hours by better managing all your projects, clients and working hours. Used by professionals and project-oriented businesses worldwide to perform essential functions such as timesheet reporting and project management. Upgradable to multi-user version with advanced functionality, web access and reports. Increase your profits!

Journyx
Journyx Web-Based Project/Effort Tracking

Journyx Timesheet: an effective way to track time, manage your projects and acknowledge workers. Enterprise ready, scales from 1-10,000 users.

Team Interactions
EnterPlicity

EnterPlicity enables organizations to increase project visibility, establish more consistent project management approaches and make better and more informed decisions across your organization without the burden of a full-blown, large enterprise solution.

Daptiv
OnDemand Collaborative Business Software

Daptiv PPM is the industry’s leading Project Portfolio Management solution. The on-demand collaborative business software allows you to select, staff and manage projects across teams, departments and divisions. Employees and team leaders effectively collaborate on day-to-day tasks via an intuitive Web interface, while business managers and executives gain visibility into project, program and portfolio execution, easily measuring progress against key business priorities.

Free Demo available

Replicon
Web TimeSheet: Project Costing and Time Tracking Software

Web TimeSheet is a completely web based software solution for time & billing, project tracking, and time & attendance. Insight Reports and enhanced scalability enable both large and small companies to empower employees throughout their entire organization. The only software required on the client PC is a standard, JavaScript-enabled Web browser. Web Timesheet is installed on your Web server and comes with all the required components. Users log in from any browser-equipped PC and enter their work time with password control. Administrators can easily generate reports by group, project, individual, or enterprise. Web Timesheet uses the Microsoft Jet database engine and doesn't require additional database software. No programming or HTML scripting is required.

FREE Trial – Demo available

DOVICO Software
DOVICO Timesheet: Project Management

DOVICO Timesheet is a powerful software solution that monitors project costs, employee timesheets, and expenses. Our software has been tested and proven by thousands of companies like IBM, Honeywell, Blue Cross and Motorola. Whether you're a leader in your field today or just on your way to becoming one, DOVICO Timesheet can help increase your profits and provide improved project control. Two way links with Windows Authentication (LDAP), QuickBooks, Microsoft Project and Microsoft Project Server assure easy data transfer. CMMI, SOX, DCAA Compliancy included.

Trial Free for 30 Days available

Systemates Inc.
Projectmates: Enterprise Wide Project Lifecycle Management

Projectmates is an affordable, flexible, web-based project collaboration portal that is available as both an installed or ASP/hosted solution. Projectmates enables you to better manage tight budgets and tighter timelines by improving process efficiency, increasing productivity and reducing operating costs. Easily connect project teams across the office, or across the world and build secure collaborative web-based project sites to share project-related data. With Projectmates, you’ll save time and money by and improve decision making by more easily manage tasks, change requests, documents and streamlining your entire business workflow.

Live Demo - Brochure available

Autotask
Web-based Project Management

Autotask is a 100% web-based solution that requires no expensive hardware or software to install, no large upfront fees, flexible licenses that let you add and decrease users whenever you want, and access to project data from any PC, any where, at any time. But Autotask goes beyond Gantt Charts, task lists and milestones. It includes built-in time-tracking and billing, hooks to QuickBooks, integration with Outlook and more. And, if you are a professional services organization, you’ll really benefit by turning on the free CRM and Service Desk modules that are built right into Autotask.

Personalized Product Demo – Trial FREE 30 days available

OpenAir
OpenAir Web-Native PSA Software Solution

OpenAir is the Web-native professional services automation solution that helps independent software vendors, marketing services companies, consulting firms, and internal corporate service organizations increase top-line growth, improve operations and enhance financial controls. OpenAir customers increase profits by capturing additional billable hours, increasing employee utilization, streamlining project management, accelerating revenue, enhancing collaboration, improving revenue recognition and project accounting, and sharing knowledge and best practices throughout the organization.

Demo available

Asta Development
Asta Easyplan – Seriously Simple Project Planning Software

Asta Easyplan is a simple project planning software product that makes it easy to create plans quickly and easily, manage project progress, track costs and produce professional looking print-outs. It is a simpler version of Asta Powerproject, the UK's most popular construction project management software. It can handle up to 250 activities at a time, making it ideal for managing smaller projects. Asta Easyplan costs from just £249 + VAT, including a 1-year technical support contract with unlimited phone and email access.

Free 30 Day Trial available - Buy Online available

Same-Page
eStudio: Web-based Project Management & more

eStudio integrates project management, document management, online calendars and contact management into a single, affordable web-based solution. Now your business can schedule calendar events, manage documents, organize contacts and manage projects anytime, anywhere! Designed for businesses, agencies, and organizations with multiple offices, eStudio improves workflow, enhances communication between workgroups and clients, increases productivity and facilitates project success! eStudio is a scalable product that will grow with your business, and can be implemented in only minutes.

Online project management and collaboration software FREE trial for 30-days available. Online Tour available

Intaver Institute
RiskyProject - Project Risk Management Software

RiskyProject is a project planning, quantitative risk analysis, performance measurement software that project managers can use to plan and implement project with multiple risks and uncertainties. RiskyProject analyzes the project schedule and risk lists together, performs Monte Carlo simulations, and calculates the chance that project will be completed within a given period of time and budget. RiskyProject also determines critical risks and critical tasks, and presents the user with results in formats that are easy to read and understand. Project schedule can be created in RiskyProject or imported from Microsoft Project. RiskyProject employs Event Chain Methodology to analyze project uncertainties defined by multiple risks.

30 Days Trial Version available

Airframe Business Software
Airframe Project Management Application

Airframe provides a cost-effective family of hosted business applications to help small and mid-sized businesses, and departments within larger organizations, become more organized, more productive, and more efficient by bringing structure to their day-to-day project management activities—and keeps customers, employees and partners working together. Airframe customers get immediate access to an easy-to-use project management application to manage projects, resources, prioritize activities, manage responsibilities, time sheets and more. Airframe is 100% web-hosted software, with nothing to install, just a standard Web browser for the PC or Mac.

Online Tour – Webinar available

@Task
@task - Project Management Software

Web-native, flexible and extensible project management for the enterprise. Includes tools for project management, help desk and request management, schedule prediction, resource allocation management, work costing and budgeting, document management, timesheet and time tracking.

Taskland.com
Taskland - Affordable Project Management for Small- & Medium-sized Businesses

Taskland.com provides affordable, easy-to-use project management software and superior customer service at a price every organization can afford. Taskland includes many everyday office tools, MS Project integration, and powerful project & task management capabilities, yet is intuitive and easy-to-use. As a hosted ASP service, Taskland minimzes your risk by eliminating any contract or long-term commitment, offering per-user/per-month pricing, and enabling real-time access to your data from anywhere/anytime via an Internet connection.

Product Tour - Free 30-Day Trial available

InQuest Technologies
InQuest Project & Program Management

InQuest Project & Program Management is a feature rich solution built using a 100% Internet architecture. Users are able to securely access documents, tasks, action items, calendars, and much more through a standard web browser. InQuest offers a more efficient way to securely share information, coordinate workflow activities and deliver project success.

DecisionEdge
DecisionCharts for Microsoft Office Project

DecisionCharts for Microsoft Office Project gives managers the enhanced charts they need to better understand and communicate key project information. With seamless integration into Microsoft Office Project, more than 80 new and improved multi-project charts are just a few clicks away.

Free 15-Day Demo - Chart Gallery - Chart List available

VirtualBoss
Construction Scheduling & Project Management

VirtualBoss is an affordable, easy to use job scheduling, and task management software solution designed for Home Builders, General Contractors, Remodelers, Trades persons, Developers, Real-Estate Property Managers, & Related Businesses. VirtualBoss streamlines your scheduling and project management functions without wasting any time with setup or learning how to make it work. Setup is a snap, and no training is necessary. You could be up and running today. Works with MS Windows or any Palm/PocketPC device. Comes with a 30 day money back guarantee.

Demo available to download

VertabasePro
Vertabase Pro - Project Management Made Easy!

Top-rated web-based project management application. You get great features with powerful reports in an easy-to-use package. All-inclusive pricing means you get unlimited projects in a web based project tracking tool along with the training, consulting, on-going project management software support and five-star customer service to make your implementation a success. Vertabase Pro gives you the best approach to project management. Easy to use and Robust. Visit the site for a tour!

Product Tour – Demo available

Epicor
Epicor Enterprise

Epicor for Service Enterprise's Project Suite offers comprehensive project management and delivery management capabilities to ensure your service engagements are executed effectively and to plan. Leveraging XML technologies with a powerful, bidirectional integration to Microsoft Project Enterprise, Epicor Project Suite provides a rich, end-to-end project management solution, offering strategic value and a quick ROI.

Comprehensive brochure - Product Virtual Tour available

PRL Info Systems
PIMARC

PIMARC is a total project management solution for the Land Surveying, Engineering, Property & Building Management Services, Architectural and Construction Industries. The application, PIMARC, has become a base unit that is installed with the understanding that it can be easily customized to slide effortlessly into an ongoing process with little disruption and the added benefits the application presents.

ProjectSpace
ProjectSpace - Project Management Software

ProjectSpace is a leading provider of Web-based collaborative project and process management solutions on the Web. ProjectSpace provides Web-enabled and WAP-enabled end-to-end solutions for project-based businesses. ProjectSpace applications provide solutions for project management, team collaboration, project portals, project extranets and online project offices.

Project InVision International
Project InVision - Project Management Software

Project InVision delivers a complete web-based Project Portfolio Management solution that provides end-to-end lifecycle management for portfolio analysis, program and project management and production support.

More detail here

Project Management Glossary

2008-03-13T00:41:00.000-07:00

Term	Definition
Acceptance Test	Final functional testing used to evaluate the state of a product and determine its readiness for the end-user. A ‘gateway’ or ‘milestone’ which must be passed.
Acceptance Criteria	The criteria by which a product or system is judged at Acceptance Test. Usually derived from commercial or other requirements.
Alpha	The first version of product where all of the intended functionality has been implemented but interface has not been completed and bugs have not been fixed.
ATP	Approval to Proceed, management approval that a project may go on to the next phase
Audit	Review of project to assess compliance with requirements, specifications, baselines, standards, procedures, instructions, codes, contract requirements, and/or license requirements
Baseline	A snapshot at a particular point in time of part of a project plan. A “schedule baseline” is a snapshot of the schedule at that point in time. Can be compared over time.
Beta	The first version of a product where all of the functionality has been implemented and the interface is complete but the product still has problems or defects.
Big-Bang	The implementation of a new system “all at once”, differs from incremental in that the transition from old to new is (effectively) instantaneous
Black Box Testing	Testing a product without knowledge of its internal working. Performance is then compared to expected results to verify the operation of the product.
Bottom Up	Building or designing a product from elementary building blocks, starting with the smaller elements and evolving into a lager structure. See “Top Down” for contrast.
Change (as in Change Control, below)	Any alteration of the functional or physical characteristics of a project work product. This includes both defect repairs and enhancements
Change Control	Process by which a change is proposed, evaluated, approved or rejected, scheduled, and tracked to completion
CM	Configuration Management (also known as SCM, Software Configuration Management)
Commitment	Pact between two or more people who trust each other to perform; commitments are freely assumed, explicitly defined, and visible
Configuration	Functional and physical characteristics of hardware or software as set forth in technical documentation or archived in a product; requirements, design, and implementation that define a particular version of a system or system component
Critical Path	The minimum set of tasks which must be completed to conclude a phase or a project.
Deliverable	A tangible, physical thing which must be “delivered” or completed at a milestone. The term is used to imply a tactile end-product amongst all the smoke and noise.
End-user	The poor sap that gets your product when you’re finished with it! The people that will actually use your product once it has been developed and implemented.
Feature/Scope creep	The relentless tendency of a project to self-inflate and take on more features or functionality than was originally intended. Also known as ‘scope creep’.
Impact	The relative harm or damage to a project if a risk becomes a problem, usually expressed either as a dollar amount or on a scale from 1 to 10
Incremental development	The development or a product in a piece-by-piece fashion, allowing a gradual implementation of functionality without having the whole thing finished.
Independent Audit	Independent review of a project by an outside agency or team separate from the organization responsible for the project, to assess compliance with product requirements, specifications, baselines, standards, procedures, instructions, codes, contractual requirements, and/or licensing requirements
Independent Verification and Validation (IV&V)	Verification and validation (see entries elsewhere in this Glossary) performed by an organization that is technically, managerially and financially independent of the development organization
Issue	Any area of concern that presents an obstacle to achieving project objectives
Lessons Learned Session	Same as Post Project Review
Major Information Resources Project	Defined in the General Appropriations Act as any information resources technology project identified in an agency operating plan whose development costs are over $1,000,000 and includes one or more of the following: requires a year or more to reach operational status; involves more than one agency or government; or materially alters work methods of agency personnel and/or the delivery of services to agency clients
Milestone	Scheduled event used to measure progress in a project. A significant point in a project schedule which denotes the delivery of a significant portion of the project. Normally associated with a particular “deliverable”.
Milestone Review	Formal review of management and technical progress of a project
Not Invented Here (NIH)	The attitude of resisting anything that was not invented or derived by the using organization or person
Process Assets Database	Organization collection of defined policies, processes, procedures, and templates. This may include structured collections of lessons learned on projects.
Project	A temporary activity characterized by having a start date, specific objectives and constraints, established responsibilities, a budget, a schedule, and a completion date
Project Completion Review	Same as Post Project Review
Project Development Plan	Document describing the approach that will be taken for a project; typically describes the work to be done, resources required, methods to be used, configuration management and quality assurance procedures to be followed, schedules to be met, and the project organization. The plan is required for all projects, but is only submitted to the Quality Assurance Team when requested. The plan will be used by the Team to analyze the status of the project. Amendments to the plan may trigger a reassessment of risk and monitoring levels
Project History Database	An organization collection of reusable data about individual projects; generally information about plans and the actual results at project completion
Project Management	System of procedures, practices, technologies, and know-how that provides the planning, organizing, staffing, directing, and controlling necessary to successfully manage a project
Project Postmortem	Same as Post Project Review
Prototype	A simple model of a product which is used to resolve a design decision in the project.
Quality Assurance (QA)	The process of preventing defects from entering a product through best practice. Not be confused with testing which is done to remove defects already present.
Quality Assurance Team (QAT)	The QAT is composed of representatives from the Department of Information Resources and the State Auditor’s Office. The Team is responsible for reviewing, approving, and overseeing major information resources projects.
Requirement	A statement of need from a project stakeholder which identifies a required attribute of the system or product to be delivered
Risk	The possibility of an act or event occurring that would have an adverse effect on the state, an organization, or an information system. Risk involves both the probability of failure and the possible consequences of a failure
Risk Exposure	The level of loss presented to an organization by a risk; the product of the likelihood that the risk will occur and the magnitude of the consequences of its occurrence
Risk Factor	An element of project development and management that is used to evaluate a project. It is an element that has the potential to affect the success or failure of the project. Risk factors can be both internal and external to the agency. Each risk factor should be addressed and controlled as much as feasible by the project management team
Risk Management	A process used to identify potential problems before they occur, so that actions can be taken to reduce or eliminate the likelihood or impact of these problems should they occur
Risk Mitigation	Actions taken to reduce the likelihood of a risk occurring as a problem, or to reduce the impact if it does occur
ROI	“Return On Investment” – a ratio which compares the monetary outlay for a project to the monetary benefit. Used to show success of a project.
Scheduling	Determining the start and stop time of each activity and task in the project, taking into account the precedence relations among tasks, the dependencies of tasks on external events, the required milestone dates, and the resources available
Show Stopper	A defect that is so serious it literally stops everything. Normally given priority attention until it is resolved. Also known as “critical” issues.
Software Acquisition Management (SAM)	The actions taken by management with a supplier or subcontractor in the process of acquiring software
Software Configuration Management (SCM)	A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements
Software Quality Assurance (SQA)	A process by which an organization determines that software it produces and/or acquires satisfies the organization’s technical and administrative performance requirements, relatively free from discrepancies, and meeting user needs. SQA must be part of an organization’s culture to ensure all of its products and services are of the highest quality
Stakeholder	Any individual or group who cares about the effort and cost of a project, wants to see the agency use the results of the product, needs to provide time and effort to make the product usable
Standard	Approved, documented, and available set of criteria used to determine the adequacy of an action or object
Testing	The process of critically evaluating a product to find flaws and to determine its current state of readiness for release
Top Down	Building or designing a product by constructing a high level structure and then filling in gaps in that structure. See “Bottom Up” for contrast
Usability	The intrinsic quality of a product which makes it simple to use and easy to understand and operate. Often described as the ability of a product to not annoy the user.
Validation	Determining the correctness of a work product, with respect to the user’s needs and requirements (Is this the right product?)
Verification	Determining whether the products of a given phase of the life cycle meet the requirements established during the previous phase (Are we building the product right?)
White/Glass Box Testing	Testing a product with an understanding of how it works. See Black Box Testing.
Work Breakdown Structure (WBS)	The complete list of activities that need to be done for a project, used for estimation and scheduling the work
Work Product	Any tangible item that results from working on a project function, activity, or task

Source : DIR , Nick Jenkins

A View of Project Management

2008-03-13T00:37:00.000-07:00

What's your project?

A fund-raiser to fix the church roof?

A five-year programme to completely re-organise the way services are delivered in your Borough?

A special event to celebrate the launch of a new product?

A marketing campaign to increase sales?

Installing a new kitchen?

Running an IT project with contributors in six different countries? With, perhaps, six different employers?

Planning your summer hols?

The list is endless: we are all of us surrounded by projects, and they all have some things in common. They have a beginning, middle and end (and here you thought we were just a bunch of pretty faces!).

Yes, we know it's common sense, but it is amazing that this is one thing that can get missed right from the get-go: all projects have a beginning point and an end point and they set the parameters for what's possible to accomplish and when. More on this anon.

Some projects are more complex than others. Some projects rely heavily on the input of a vast range of people, while some only rely on one person to get them done. Summer hols planned by Committee can be a disaster!

For the sake of this document, we will concentrate on work-related projects, but do know that anything we suggest in this context can (and 'should') be used in just about any project you've got on the boil (or about to be boiled).

Getting started

Having an idea of what you want to achieve is a good place to start. Most of us recognise that a project should have a good business outcome but what about the people involved? Including you!

Most people involved in a project will get something personal out of it – even if only a headache. Putting your focus on that personal outcome, deciding what it is and why you want it gives you a better chance of getting it and of finding the motivation to keep going when things aren’t going to plan.

You might want to start by asking yourself:

§ What do I want from this?

§ Is it possible?

§ When and where do I want it and with whom?

§ What might I have to give up or lose to get it? And is that OK?

§ Who or what do I need to have to make it possible?

What you want might be fantastic and it’s great to shoot for the stars but a reality check is good for your sanity. So, work out the workable options for your great outcomes.

Knowing where to stop is often a problem, whether it’s a project pushing back the boundaries of science or decorating the spare room – so how will you know when your project has reached its intended end? What will it be like? The clearer you are at this point the easier it will be to recognise when you get there – a bit like planning a journey, you usually want an idea of the destination before you set out.

What do you need?

OK so now you know where you are going and how you'll know when you've got there so all you need now is to kit up for the journey. Take a look at what you need for your ideal outcome – people, kit, space, money, time, etc.

Add to that list the inner resources that you or others will need - commitment, enthusiasm, motivation. The best-planned projects can fail because the hearts and minds of the people involved have not been won over. On the other hand there are lots of projects that would never have got off the ground but for one or two champions who didn’t understand the concept of failure. Their self-belief, enthusiasm or sheer bloody-mindedness carried them through. What inner resources would give your project a momentum all of its own?

Oh for a project where all the people, time and commitment we need are all available! Life is rarely that simple. Take a look at what you realistically have got or can beg, borrow or steal (figuratively speaking of course!) to make your project a success. Who will you have to negotiate with to get the best resources? What can you trade? Who do you know and who can you influence? Bribe? Blackmail?

Most of us have a friend with a cousin whose partner’s uncle works for a guy with just the thing that you need for your project.

So where there is a gap between what you need and what you’ve got, you might want to take a look at who you know and who they know. Take a look at the person that has what you want and work back from there. Who is in their inner circle? And how can you get at them from your circle of influence? It might take a few connections along the way but worth the effort if it gets you what you want.

At the end of the day you will have a set of resources that are available to you in your project. It may be that the budget is less than planned or the ideal member of staff isn’t available. How does that affect your planned outcome?

Planning

Planning is a joy to some and a nightmare to others. If planning is second only to having teeth extracted without anaesthetic on your list of pet hates then try to enlist someone who loves it. They’ll have it mapped out for you in full Technicolor with delivery dates, critical paths (see below), resource allocations and budget projections before you can say ‘Millennium Dome’.

Otherwise knuckle down and look at what you want to achieve, draw up a list of actions and get going with who will do what by when, how long it will take and how much it will cost.

There are some things that can happen pretty much any time during a project as long as they happen. Others are vital.

When we were having our loft converted the painter couldn’t start until the plastering was done, the plasterer couldn’t start work until the electrician had finished wiring up, but he needed the plumber to have finished plumbing in the shower before he could connect it up. The plumber was waiting for a very small but vital part that was missing from the shower. The part was on a six-week order so work ground to a halt till the very small part arrived in the post!

Some things on the critical path will only become obvious when they arise but most can be built into the plan. The crucial thing is to let people know what the critical bits are so, if they are responsible for them, they know what the effect will be if they are late. Others need to know which bits they have to wait for before they can start work. A little bit of forethought and clear communication can avoid heated discussions, frustration and late delivery.

Once you have your plan of what needs to be done and your critical path you can schedule all the tasks to take you through to your delivery date. Till you get stuck and can’t think what needs to happen next…..

A really effective way of planning that can help – especially when stuck – is to work backwards from your ideal goal.

For example, if I have to deliver a new software package by the end of December, I will need to have the client acceptance tests by the end of November to allow time for final adjustments. So internal testing will have to start by beginning of November. That means development will have to be complete by end of October. If I have a 1 September start date I have eight weeks for the development. If the end date can’t move I might have to limit what I can deliver to what is feasible in that eight weeks, rather than the all singing, all dancing, whiz bang development I had originally planned.

Budgeting

A project that comes in on-time and on-budget is as rare as a perfect summer. Now, of course in this year of 2006 as I'm writing this, we do seem to be having a perfect summer - blazing hot Mediterranean days, barbeques, lazy days. Does seem perfect. Oh! I spoke too soon. No rain. See, we told you perfect summers are rare.

We all set out with optimism and a real belief that it will happen and we make our plans accordingly. We are then surprised and disappointed when it doesn’t work out that way. Budgets overrun and we wonder how it happened, much as we wonder where the rain is when we've just planted up a new flowerbed.

Budgets should always have some leeway in them for the things you have forgotten, the disasters that emerge or the miscommunication that always happens along the way.

Letting the people responsible for various tasks know what the budget is that they are working to is always a good idea and the sooner the better. Preferably before they order the individually hand-crafted, bejewelled, designer fountain pens as a giveaway on your exhibition stand at Manufacturing Today.

The team

Take a look at everyone in your project team and think about the role you want them to play.

Too many...

... cooks spoils the broth.

... chiefs and not enough Indians.

... projects fail because no-one knows what their roles are.

Take your pick. So be clear who is responsible for what, who the decision makers will be, who is going to manage, who is going to do what, who just needs to know what is going on and who needs to agree to something. Then tell them.

Sounds obvious but sometimes we don't do it because we don't want to offend someone who is expecting a bigger role or because we think everyone knows what is expected of them. At Impact Factory we think you can't clarify enough. Let everyone know where they stand and what’s expected of them.

You may decide to adopt a laissez-faire management style, just assigning tasks and letting people get on with it. Great if that is your style. It is good for the confidence and self esteem of the members of the project team to have a measure of independence and trust shown. But if there is a part of you that worries when you don’t hear anything, or if you think that some members of the team might not have the confidence to speak out when things start to go pear shaped, for your own sanity you might want to consider a balance between how much you trust people to get on with things and how much reassurance you need that they will do it.

The balance is to make clear what you need to feel OK about letting go of the day-to-day detail. It takes a sizeable measure of will power and a good dose of allowing mistakes to happen, or sometimes just accepting that things won’t necessarily be done the way you would do them or as well as you would do them (face it, who could do it as well as you?).

It can be very easy to rely on people to tell you when they need help - they won't most of the time, until they're glubbing down for the third time and all you see are the bubbles on the surface of the water. Putting in place some kind of support mechanisms such as regular scheduled check-ins and reviews, both individually and as a team can keep things in balance. Sometimes things need to be more formal, in larger projects with a buddy system and other things that can be built-in so that people feel well looked after.

The creative stuff

Ever set out on a project that you know will be great if only you knew where to start? Or maybe one where you need some ideas to get past a rather vague bit in the plan? So thinking caps on and see what you can come up with. Great! But sometimes all anyone comes up with is the same old, same old. We have a few ideas for getting those creative juices flowing.

It’s like a train setting off on a journey and just going down the same railway lines each time. If you want it to go by a different route try giving it a different starting point. So to cut some new paths in the brain we start with something different.

There are lots of different techniques for brainstorming – we give you a couple of ideas here but feel free to come up with your own!

The jelly method

With this one you start with a word that has nothing to do with your project or the problem you are brainstorming. Like 'jelly'. Then you list all the properties of jelly- it’s wobbly, sweet, different colours, fruity, children like it, good for parties, etc. Then you look at making connections between those properties and the subject, sometimes with a couple of other steps in between - stepping stones.

So if you are looking at a project to redesign your office space you might go from wobbly to flexible to hot-desking. Or to a new concept in supportive seating. It doesn't matter if you can't see the 'logical' connection; the important thing is to generate lots of ideas that you can sift later.

The ridiculous

With this one you start with a ridiculous condition. So, for the office redesign project you might start with something like:

The staff are all lobsters

OK so we get things like:

Water tanks, special food piped in daily, temperature control, specially modified equipment, translation services…

Again the more ridiculous the ideas the better because it might trigger a humdinger of an idea for something real along the way.

Inversion

Turn the world upside down. How could you make your project fail miserably? What would it take for the worst-case scenario to become a reality?

And then before you curl up in the kitchen in a foetal lump, turn it all over and see what you have to do to protect your project and make it a success. What could go right? If all went swimmingly well (indulge me) what might happen?

Take a look at the ideal outcome for your project and the ideal happenings along the way. Just thinking about the things that could go right might give you some ideas about how to make them happen.

Probability x impact = priority for plan B

Similarly putting some effort into thinking about what could go wrong allows you to put a plan B (C or D) in place. This is a really good idea when the probability of something going wrong is pretty high. Like the most crucial delivery being late - it's always the crucial deliveries that are late so plan for it.

Getting people on board

So you have your gantt charts, work package descriptions, critical paths and resource allocation sheets but what about the hearts and minds of the project team?

Tapping into what makes people tick is a sure fire way to motivate them. Bribery is underrated as a management tool. You just need to figure out which bribe works best for each person! In our experience the list of things people say motivates them is delightfully varied. It includes things like praise or acknowledgement, challenge, responsibility, promotion, satisfaction of seeing a job through, achievement and learning something new. OK so money is usually in there too but it is just one of many things and often not top of the list.

One thing is sure - if you can't find anything to motivate someone to get on with some part of your project then things will be a bit harder than if you can. So for the important bits on your critical path it could be worth putting some effort into working out why they should care.

Especially true when you have no direct control over the people or resources concerned. You might need a bit of kit that Fred in supplies keeps under lock and key or a few weeks of Jane’s time from IT and she is overloaded with other work. So how do you get what you want?

Well, who has the say so? Having worked out who the person is that you need to be nice to you have to see things from their point of view. Fred may be precious about the bit of kit because it is costly to replace or because other people haven’t brought it back when they borrowed it. Acknowledging how Fred sees the world is a good starting point for the discussion.

Is there anything you can offer to the person you are trying to influence that might help? An assurance, extra resource, a favour returned? Think outrageously – bribery, corruption, illegal acts and then see if something real springs to mind – we definitely don’t recommend the illegal!

The C Word

All the way through the project the key to success is often communication - keeping people informed about deadlines, expectations, progress, changes etc. It may seem like a big job but the job will be bigger if you don’t. Cleaning up after a miscommunication, or a missed communication, often takes much longer than telling people stuff from the start.

It’s a really good idea to have a communications plan in place right from the off and review it just as you do your project plan; ‘What’s worked, what hasn’t, what else do we need to do?’

Getting heard upwards, downwards, sideways

Occasionally you want to get a message through to someone higher up the chain. If you have ever felt like a voice crying in the wilderness at this point then take some comfort from the fact that you are not alone - that's the problem really. There are so many others trying to get the attention of that person you might as well be crying in the wilderness. In fact that's not a bad idea because at least it would be something different and that's what you need to get noticed above the general hubbub of lost souls needing the bosses attention.

So take responsibility for being heard, make your message clear and concise then SHOUT. Not literally (unless you think it might help) but get your message across in a way that gets the attention of your target audience.

If you're communicating downwards or sideways its not that different. Being concise helps, as does being absolutely clear about what you want the person to do. Put some attention on how you want the message to be received for a really impactful delivery

Monitoring

Your project is underway, you have communicated well and often, things are taking their proper course so you can sit back and relax, right? Wrong!

It’s a bit like spinning plates, you have to be constantly looking for the one that’s about to drop off, slow down or spontaneously combust (it happens!).

Monitoring the progress of your project, keeping a wary eye on the areas where problems are likely to arise and anticipating difficulties ahead of time can save time and grief later.

Even if everything is going to plan it is important to let people know. We have seen many projects lose momentum because the project manager has sat back when everything is going to plan. Keep your project in the front of everyone’s mind with regular progress reports.

The Best Laid Plans of Mice and Men….

(….and contractors who don’t deliver on time, reports that don't get written, deadlines that don’t get met, people who don’t show up, promises that aren’t kept. Etc., Etc., Etc.)

When it doesn't go according to plan or someone/something throws a spanner in the works…..

PANIC!!!!

Alternatively, take a deep breath, notice that this happens to other people too and decide how you want to handle whatever disaster has occurred. At this point you may have to put plan B into operation but if this is an unforeseen disaster then you may want to stand back from it and take a new look. And by that we don’t mean looking for someone to blame for the sorry mess.

As the Titanic sank I suspect there were one or two people worrying about whose fault it was and why it happened. Most people were probably looking for a lifeboat. The captain’s job was to look at the situation as a whole and decide how best to proceed given all the variables – what are the priorities, best use of current (!) resources, how much contingency help could be at hand but how to get them on board (!!) in time, who needs to know and what do they need to know, etc. Your project is no different.

Taking Care of Your People

Do you like to be thanked for putting in an effort on something? How often does it happen?

If what we hear is anything to go by, then not nearly enough as we would like. When we look at what motivates people acknowledgement is almost always on the list and often near the top. So taking the time to acknowledge a job well done is worth a few moments of your time.

Even if things haven’t gone so well it’s worth making the effort to give feedback. At Impact Factory we like to think about feeding something in someone.

So what is it you would like to feed in your project team or in one individual? A sense of…. achievement, urgency, pride, responsibility, etc. Choose the impact you want and then deliver your message holding that as the intended effect and see what happens.

Take a look at the other stuff that motivates your team. Is there anything you can do part way through your project to make sure they stay motivated through to a successful conclusion? This is especially important if you have had a disaster or two along the way. What has gone right? What successes can you celebrate so far? Who has gone the extra mile?

One of the things that keeps people motivated and pulling together is the sense of having some say in what is going on so try getting input from the team on how they think things have gone and what the future direction should be. So why not let them have it?

The End is in Sight - Now What?

Imagine the church roof is fixed, the new product is launched or the kitchen is fully installed and operational. What do you do now?

Most end-of-project reviews will take a look at lessons learnt and they usually focus on what went wrong and how to do better next time. A good thing to do. We feel that knowing what went right and how you did it is maybe even more productive – it means you have more chance of doing it again!

Take a look at all the things you have achieved, how you (the team did it) and then celebrate your success: a slap up meal together, a bottle or two of bubbly, a bonus, a box of sinful chocolates, an extra day's leave. Doesn't matter what - just make sure you celebrate! For your next project you just might find that people come with a level of motivation already because they know that you will end on a high.

Talking of your next project – the church organ or the bathroom or the new widget the research department wants to launch, off you go again with a bundle of experience under your belt. So what will you do this time? How can your next project contribute to your personal goals and build on your success so far?

Before you get carried away with the excitement of breaking new ground, you might want to consider giving your brain a break. Too often people just plunge themselves into projects or juggle more than one and feel they have to keep at it and at it until it's done. They come in early, work late and as we know can get less productive the more they work on it.

So give yourself a break. Take an hour to walk in the park, or a day to do mindless paperwork or filing, play computer games, phone a friend, do Sudoku, go for a swim - pretty much anything that allows the right brain to have some breathing space and gives the left brain a rest for a while.

Even a short break can recharge the batteries and have you back rearing to go on your next ambitious undertaking. Good luck!

Authors : Bronia Szczygiel, Robin Chandler, and Jo Ellen Grzyb

Source : Impact Factory

More reference on project management :

2008-03-13T00:33:00.000-07:00

http://en.wikipedia.org/wiki/Project_management

Project Management Institute (PMI)

ITtoolbox Project Management Knowledge Base

Project Home Page – Microsoft Office Online

Project Management Help

Projects@Work

Project Management Seminars from the AMA

School of Management, Project Management Program

SAI Global Project Management Training

The George Washington University – School of Business

http://www.mapnp.org/library/plan_dec/project/project.htm