Talk:Project planning

This article has not yet been rated on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Engineering This article is within the scope of WikiProject Engineering, a collaborative effort to improve the coverage of engineering on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.EngineeringWikipedia:WikiProject EngineeringTemplate:WikiProject EngineeringEngineering ??? This article has not yet received a rating on the project's importance scale. Systems: Project management This article is within the scope of WikiProject Systems, which collaborates on articles related to systems and systems science.SystemsWikipedia:WikiProject SystemsTemplate:WikiProject SystemsSystems ??? This article has not yet received a rating on the project's importance scale. This article is within the field of Project management.

I have been in the construction scheduling business for 32 years, and have a best-selling book on the subject. Over the years we have witnessed a shift of the central mass of scheduling application from construction to software. For instance, PMI (Project Management Institute) was formed by the construction industry but today its demographic is 85% software.

There are marked differences in how planning and scheduling functions are performed in the two industries. I have added text to clarify those differences at a 30,000-foot level. I have taken the initiative to cite my own book, which spends several chapters on the difference between planning and scheduling in the construction industry.

If the changes I have made survive editorial scrutiny, then I would like to find time to add additional articles to build up the understanding of construction planning and scheduling.

I have also linked to my company's website, as ICS (International Center for Scheduling) is the world's largest construction scheduling enterprise.--ICSGlobal (talk) 12:35, 22 May 2008 (UTC)Reply

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

What's this? Could someone give more context? The article looks like as if it were an excerpt of some bussiness textbook. -- Taku 07:43, Nov 14, 2003 (UTC)

The article now lacks focus. It should ideally place Project Planning as a complementary management activity to Context-setting (Business Case, Team-building etc), Implementation, Monitoring and Control. Matt Whyndham 17:07, 24 March 2006 (UTC)Reply

The link to the planning game is broken and I would really like to see it! It is that permission is forbidden.

I removed the lengthy section below, because Wikipedia is not a how to. However it could probably be turned into something more encyclopaedic, so I've left it here if someone wants to try.

1. Determine the exact conditions for the project to be completed or to be terminated. Before it is absolutely clear what the objectives of the project are, it makes little sense to start estimating how long it will take and how much it will cost. Unfortunately, many project managers fail to take this first, crucial step. Each project should have a clear connection to one or more real of organization's business issues.
2. Make an inventory of all the work that needs to be done with an estimate of the time it will take to complete by a single team member. This can be done in a planning session with all the team members. Tasks that will take over three weeks to complete need to be broken down further to get good granularity. To avoid getting swamped with details, the tasks at the lowest level should take approximately 1 week. The result is a work breakdown structure. Make sure that having the project's deliverables injected into the organization or its environment will actually cause the expected benefits (project objectives) to materialize.
3. Identify the resources needed to complete each terminal element of the WBS. At this point you can usually estimate the cost to deliver each terminal element and, consequently, the project (bottom-up approach). Sometimes a top-down approach to estimating costs is also possible by means of using coefficients (e.g. it costs between $X and $Y to build a square meter of a house of such-and-such a standard).
4. Make a decision whether this initial plan makes sense, i.e. whether the costs justify the benefits. Modify the objectives and the supporting work as necessary.
5. Define dependencies among tasks. Some tasks need to be completed before other tasks can begin. By putting tasks into their relative completion order, a project manager constructs a project network.
6. Calculate the minimum time the project will take: it is the longest path through the project network from the start of the project until its end. This path is called the critical path (or critical chain, if resource dependencies are taken into account). Other tasks can be done in parallel to the critical path but any delay in the tasks on the critical path will automatically result in a delay in the overall deadline of the project.
7. Create a project schedule (e.g. in the form of a Gantt chart).
8. Plan for risk management and modify the project plan accordingly.
9. Commit the organization to starting the project implementation.

Project planning is not something that is done only once at the beginning of the project. It should be an ongoing task of the project manager to keep an eye on the progress of his team and update the project plan accordingly. Project management software can be helpful if used properly. There are several project management standards that describe in detail how to plan and manage a project.