Wednesday, November 17, 2010

Defining Phases and Tasks with Microsoft Project

Project management allows businesses to coordinate large projects and ensure that resources are being used to maximum effectiveness. Although this process is much easier with Microsoft Project, training helps users get the most they can out of this powerful software.

Let's look one of the early phases of project management, defining phases and tasks, and show how Microsoft Project training can simplify this process.

Define and enter tasks

Clear task definition is one of the challenges of project management and Microsoft Project training can help users understand this important step.

A task must have a clear beginning and end so the manager can see when it is complete. The level of detail depends on the scope of the project. Too much detail requires constant updates and wastes time, while too little detail means a manager may not know a project is running behind until too late.

Students learn about two kinds of tasks in Microsoft Project training: one-time and recurring. One-time tasks are entered as easily as typing in the task name. Recurring tasks also need recurrence pattern (daily, weekly, etc.) and range of recurrence.

Project management pre-planning often uses other software and Microsoft Project training demonstrates methods to import tasks from other locations.

A task list can be imported from Outlook 2003. A variety of task data can be imported from other file formats such as Excel, Access, or Microsoft SQL Server. If nothing else, task information can be simply copied and pasted.

Group tasks into summary tasks

Once all the tasks are entered, group them into an outline to make it easier to see related tasks together or see how different tasks interrelate.

Microsoft Project training shows how related tasks can be grouped under a summary task, which is a major phase or sub-phase of a project. The summary tasks combine any subtask values such as cost into sum values. Since these values are calculated, they cannot be edited at the summary task level. Instead, the planner must edit the underlying subtasks.

The summary tasks give a high-level view of the project and make it easy to monitor a project's progress. If a summary task is running behind, examination of the subtasks reveals which of them is the bottleneck.

Go back and fill in the detail

Once a list of tasks has been generated, Microsoft Project training shows how more detail can be added to each one. Notes and images give more detail about a task.

Project related documents can be loaded and assigned to the project as a whole or to specific tasks on the list. Information such as cost and work required help define a task further. The more information available, the more accurate the final project management plan will be...

Tuesday, February 26, 2008

Selecting Project Management Software

By Dick Billows, PMP, GCA

Summary: In our 5-step project methodology we take teach people to use project software so they can build schedules quickly and update them in minutes a week. We also match the project software and how we use it to the scale of the projects we manage. Most project software can be used at several levels of sophistication. There is a wide range of choices

Project management software comes in many different levels of sophistication with prices ranging from $50 to $20,000 or more. Software itself does not make project managers more effective; it just makes them more efficient. PM software does not teach you how to define scope, communicate to the project sponsor or make clear assignments to your team members. It just let's you accomplish these and many other PM tasks more efficiently. So, before we look at the different kinds of PM software let's talk about the kinds of projects you manage and the levels of PM skills. This will enable you to pick a PM softwarLinke tool appropriate for you and the organizational setting in which you operate. Decide which of the following three categories of project manager fits you best.


Source : http://www.4pm.com/articles/selpmsw.html

Inside the Sarbox: The Future of Project Management

By Jeannette Cabanis-Brewin

Naturalist John Muir once said, "Tug on anything in Nature, and you find it is connected to everything else." The same is true of business. A few years ago, in a column for my online newsletter, the Best Practices e-Advisor, I commented that all hot concepts in project management seemed to be running together in a blur (see The Enterprise Project Office Maturity Modeling Portfolio—and Other Adventures in Holistic Project Management). The trend continues; in fact, with the passage of the Sarbanes-Oxley Act of 2002, the pace at which formerly disparate parts of the organization must integrate has picked up.

In plain English, Sarbanes-Oxley (affectionately nicknamed "Sarbox" ... not to be confused with Pandora's Box) means that CEOs and financial officers of publicly traded organizations can no longer say, "Gee, I didn't know that." Post-Sarbox, "Somebody in one of those distant functional silos must have screwed up," will be no excuse when the chickens come home to roost. The "chickens"—Risky Projects, Accounting Irregularities, and Shady Deals, by name—and the contents of the "silos" are now the personal responsibilities of the top brass, with severe penalties (up to $5 million and/or 20 years in jail) for willful cluelessness.

Breaking Down Barriers

Project managers have been complaining for years that top executives weren't paying attention to the needs and realities of projects. Thanks to Sarbox, that will change. Project managers will have all the executive attention they can stand ... and then some. It's a classic case of getting what you wished for.

In a recent interview, project management expert Greg Hutchins, PMP, noted that this is "a huge, huge opportunity and challenge for project managers.... What this does is effectively erase many of the barriers between project management and finance, and between projects and the highest decision-making levels of the corporation. Project managers need to be well along on the maturity curve to handle this. A mature project manager can say what the 15 or 20 items are that might be problematic out of 2,000 items in a work breakdown structure. Those 'project breakers' transcend cost and schedule issues; they are big issues, issues that project managers once thought were outside their scope—such as regulatory compliance, the environment, internal politics, and market timing."

From this comment, it's obvious that more than finance and project management are forced into cozier integration by the new rules. The way the enterprise assesses and manages risks will also become a central issue for the people who have to certify that they have not done anything "fancy" with shareholders' money. Although Sarbox doesn't specifically mention better risk management, you can bet that anxious audit committees, CEOs, and CFOs will be reading between the lines. According to an article in the April 2003 issue of Risk and Insurance magazine, one of the most important implications of Sarbox is a bias in favor of "risk transparency." The act obligates companies not only to openly share information about known risks, but also sets up the expectation that they will have a rigorous process in place for discovering unknown risks. According to Hutchins, "risk processes throughout the enterprise are going to be under great scrutiny by regulators and by executive leadership, forging a link between the project level and the board level that has not existed before."

Sarbox, Risk, and Portfolio Management

How can an enterprise adequately manage risks without knowing exactly what is going on? The strong pressure for project portfolio management inherent in the Sarbox rules changes has only begun to be felt. Writing in a recent issue of IT Management Online, George Spafford points out that project management can only ensure that projects meet expectations and create value if the best projects are selected and approved in the first place. Hutchins agrees, calling portfolio management "a step in the right direction, as it deals with consistent processes, hopefully flowcharted, with risk points identified and controls identified." But, he notes that portfolio management is still a practice under development, not a mature practice in most organizations.

It's hard to implement portfolio management in the absence of sound project management methodology, project knowledge management, and infrastructure—including enterprise project management systems and an organizational "home" to oversee project management processes, such as an enterprise-level project office. Implementing an enterprise project office brings up the issues of organizational maturity and personal competence. It's a puzzling chicken-and-egg question: Can an organization achieve a high level of maturity in sophisticated project management practices such as portfolio and risk management without an enterprise project office in place? Can it create such an office effectively without a high level of maturity? The answer probably lies in the personal competence of project managers who are motivated to make a difference in their organizations.

Open the Sarbox and tug on one enterprise issue and you'll find they are all connected to each other. This is important and pressing news for project managers. The integrative skills that are the souls of project management have never been more needed by organizations; the pressure to perform them effectively never more intense.

About the Author

Jeannette Cabanis-Brewin (jcabanis-brewin@pmsolutions.com) writes on the organizational and human side of project management for the Center for Business Practices, the publishing and research division of Project Management Solutions, Inc. A former staff writer and editor for PMI's PM Network magazine, her feature articles have been widely reprinted and quoted in project management publications in the U.K., South Africa, and Australia. Recently, her articles on project management topics have appeared in Projects@Work, Primavera magazine, myplanview.com, People On Projects, and the Best Practices e-Advisor. She is the editor of several award-winning project management books, and author/co-author of two books forthcoming from Marcel Dekker/Center for Business Practices.

Saturday, February 23, 2008

PLANNING A PROJECT

by Gerard M Blair

The success of a project will depend critically upon the effort, care and skill you apply in its initial planning. This article looks at the creative aspects of this planning.

THE SPECIFICATION

Before describing the role and creation of a specification, we need to introduce and explain a fairly technical term: a numbty is a person whose brain is totally numb. In this context, numb means "deprived of feeling or the power of unassisted activity"; in general, a numbty needs the stimulation of an electric cattle prod to even get to the right office in the morning. Communication with numbties is severely hampered by the fact that although they think they know what they mean (which they do not), they seldom actually say it, and they never write it down. And the main employment of numbties world-wide is in creating project specifications. You must know this - and protect your team accordingly.

A specification is the definition of your project: a statement of the problem, not the solution. Normally, the specification contains errors, ambiguities, misunderstandings and enough rope to hang you and your entire team. Thus before you embark upon the the next six months of activity working on the wrong project, you must assume that a numbty was the chief author of the specification you received and you must read, worry, revise and ensure that everyone concerned with the project (from originator, through the workers, to the end-customer) is working with the same understanding. The outcome of this deliberation should be a written definition of what is required, by when; and this must be agreed by all involved. There are no short-cuts to this; if you fail to spend the time initially, it will cost you far more later on.

Next

On Software Project Management Books



Glen AllemanGlen B. Alleman Principal Consultant with Niwotridge Consulting writes...

"The following is a list of books, articles, and other references I regularly use in my consulting practice. This list is far from exhaustive, but represents a working set of knowledge about system architecture, software design, and the management of software development projects.

I continuously add to this list as I discover new material. With a nearly unlimited number of resources in cyberspace, it is not only impossible to keep up, it is also very difficult to sort out the good from the not so good. My test of goodness is "does this make sense to me?," and "can I actually confirm that the concepts in the material can be used in practice with measurable results?" The following list has served me well over time."

See http://www.niwotridge.com/Books/BooksSource.htm

Fundamental Principles of Project Management

By R. Max Wideman

Introduction

From time to time, various attempts have been made to enunciate ‘Principles and Practices’ of project management. However, there appears to be no consensus on either the principles or the practices of ‘acceptable’ project management, nor does there appear to be much documentation of any ‘theories’ of project management either supporting these principles and practices or derived from them. Thus, the foundation of the project management discipline appears to be somewhat weak.

On the other hand, there is a wealth of literature researching projects to determine what people do in project management, followed by conclusions drawn, as well as a wealth of advice on ‘How to do it better’ (practices). However, since few projects appear to pre-define their product success criteria, the results of these projects may be good, bad, or indifferent. Hence, some of the conclusions drawn may be questionable.

What appears to missing is a set of fundamental project management principles as a basis for comparison. This paper is an attempt to address this gap.

Read the full text

What to look for in project management software?

Nowadays there is an abundance of different project management tools available. This makes it harder than ever to make a determined choice. Here are some guidelines to help you pick what is right for you:

Gantt Charts
Project management software is supposed to make your life easier. Make sure the tool automatically creates Gantt Charts that you can copy and paste and reuse for reports for the senior management and other project stakeholders.

Web Based Collaboration
The days of client based project management software are over. Software as a service (SaaS) has emerged as a trend that more and more people follow. The myriad communication and remote management capabilities of web based solutions have rendered client based enterprise systems obsolete and backward.

Email Updates
Make sure the tool keeps project stakeholders in the loop via email updates on task logs. This way everyone knows what they need to know, no matter where they are.

Security
Make sure the tool uses a trusted SSL certificate so all your information is tranferred securely.

Real Support?
Does the company's website say that they offer quality email support? How about you give it a try? Shoot them an email and see how quickly they respond. If they take more than 2 hours don't waste any more time waiting on them. There are lot's of one-man-companies out there founded based upon get rich quick schemes. They spend a lot of money on advertisement and marketing but lack what actually matters: quality and the esteem to support it.

Feature Requests
When you request an additional feature, how does the vendor react? Is he open to it or does he shun your request? There are actually really successfull tools out there whose owners constantly refuse to add the most basic features, like gantt charts and discussion forums!

Server Performance
Very important! Make sure the company hosting your solution uses a decent, fast, and secure high performance server. Lots of solution providers ignore this vital requirement. Without a decent server, a web based solution is not worth a dime.

Tracking and Reporting
Why do you need a project management tool in the first place? To track progess and to create reports about that progress. A solution without these feature need not call itself a project management software.

Pricing
There used to be a time when large companies enjoyed a monopoly on project management tools and charged amounts like $200 for one (!!) license. The web has enabled more companies to offer solutions at much more reasonable prices. But even solutions for more than $10 per license deserve to be looked askance upon. Make sure you don't overpay just because you need a quick decision.

Free Trial
The project management software you are considering to use should offer a free account type. You should be able to use this, albeit limited, account as long as you need to in order to evaluate the tool and have you colleagues and managers look into it. If the project management software provider does not offer a free trial he surely does not have a product that he expects you to like.

Source : Project Centers