Project Management Software based on Project Management Book of Knowledge, Source for Project Manager. Project management is the application of knowledge, skills, tools and techniques to a broad range of activities in order to meet the requirements of the particular project. A project is a temporary endeavor undertaken to achieve a particular aim. Project management knowledge and practices are best described in terms of their component processes.
Wednesday, November 17, 2010
Defining Phases and Tasks with Microsoft Project
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
Inside the Sarbox: The Future of Project Management
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
Fundamental Principles of Project Management
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.