Whether you bill clients hourly or on a per project basis, a necessary step of all projects is estimating the time

it will take. Not only does the client want to have an idea of how much money they will be spending, but they also need to plan around an estimated timeline. And you need to be able to ensure you have the time and resources necessary to complete the project. Depending on a number of factors, including how much experience you have with the type of work youre doing, if you are using subcontractors, and the information you have from the client, estimating the time for a project can be difficult. Here is the process I use when scoping the time commitment for a new project. Identify Deliverables The first step is to identify the main project (i.e. Website Redesign), and then pinpoint the specific deliverables associated with the project. For example, upon completion of the redesign, you will be providing the client with a newly designed website by FTPing the site files and sending the client a CD or USB drive with the working files. Break It Down Next, I take the project and break it down into simple tasks separated by component the more specific the better that will get us to the deliverables. Here is an example of what the tasks may look like: Project Planning

Initial meeting with client to gauge scope of project Provide client with project information sheet to get more information about what they like/dont like about their existing site Review/analyze existing site and client form Develop list of areas site changes to be made Get approval from client

Design

Design site mockup Get approval from client Code pages Create new navigation Reorganize content into new pages Optimize for SEs

Testing

Cross-browser testing Validate code

Check links Test forms

Add It Up The next step is to estimate time for each task, rounding up. If you are using subcontractors, you will need to get their time estimates first and work them into your time. Then take the total time for all of the tasks and add in a buffer. The buffer can be anything, although I usually stick with a 10-25% addition. This allows for any unexpected situations or challenges that arise. Things to Keep in Mind The more time estimates you do, the more accurate you will be. As you create your own formula, some other factors you may want to consider include:

Project management time Time to review work of subcontractors Holidays or days off that occur during the project Client turnaround time Debugging

How do you ensure your time estimates are as accurate as possible?

Work Breakdown Structure

I
B y D i c k B i l l o

w s , P M P , G C A
S

T o o m a n y p r o j e c t m a n a g e r s b u i l d a W B

S t h a t g i v e s t h e m n o f o u n d a t i o n f o r c l e a r a s s i g n m e n

t s , c l o s e t r a c k i n g o r t i g h t s c o p e c o n t r o l . I n o u r B e s t

P r a c t i c e s M e t h o d o l o g y w e f o c u s o n h o l d i n g t e a m m e m b

e r s a c c o u n t a b l e f o r a c h i e v e m e n t s , n o t m i c r o m a n a g i

n g t h e m . B u t t o o m a n y P M s u s e t h e " t o d o " l i s t a p p r o a c h .

WBS: It's Not a "To Do" List

These PMs think their work breakdown structure (WBS) should be a "To Do" list for the project so they can tell everyone everything they need to do. As a result their projects fail most of the time. Yes, its those PMs who are to blame for the 70% project failure rates you read about. Let's see why. They create this big list by writing down what needs to be done in order, from first to last. That approach requires little thinking and not much time and in a short while they have a long list of "to do's." When a PM takes that approach these things happen:

The project takes about 50% longer than it should The "To Do" list expands weekly during the project's entire life The project manager makes vague, unclear assignments to the team The team spends hours in status meetings discussing what to do next The project finishes late and requires weeks of rework after it is finished.

Work Breakdown with Measurable Outcomes for Each Entry

To avoid this nasty list, we teach project managers to decompose the project's scope into the WBS. Decomposition takes longer than jotting down a "To Do" list and it requires a lot more thinking. But taking that extra time and doing that thinking gives you a professional-grade WBS. Consistently successful project managers always use decomposition because is saves time during the project and makes for better control.

WBS: It's a List of Measureable Deliverables or Achievements

Look at the section of a WBS below. It was developed using our Best Practices

Methodology. The PM took the scope and decomposed it into 7 high-level achievements (3 are shown in the screen shot). Then the high-level achievements were in turn decomposed in to smaller achievements. Then we further divide those achievements down to the level of individual assignments. This process takes some thinking and you need to master the right technique but consistent success on your projects requires that you master these skills.

How Many Tasks Should This Project Have?

There is no magic number but the usual mistake project managers make is to lay out too many tasks. Their work breakdown structure (WBS) is a "To Do" list of one-hour chores. It's easy to get caught up in the idea that a project plan should detail everything everybody is going to do on the project. This springs from the screwy logic that a project manager's job is to walk around with a checklist of 17,432 items and tick each item off as people complete them. This "To Do" list approach is usually linked with another fallacy. Namely, that the project plan should be a step-by-step procedure for doing everything in the project in case we have to do it again. If the PM is managing the wrong things, this may be handy because we increase the odds of having to do this project again. Sponsors encourage these fallacies by marveling at monstrous project plans because they make it seem that the PM has thought of everything. Unfortunately, on significant cross-functional projects, there is absolutely no chance that the project manager will think of everything. The subject matter experts and specialists are the ones we must hold accountable for that. The result of these fallacies is that PMs produce project plans with hundreds or even thousands of tasks. Many of them have durations of a few hours or a few days. Does this level of detail give us better control and lead to successful projects? In our view, a "To Do" list approach does not give effective control, in fact, it interferes with the achievement of a successful end result.

The "To Do" List Approach

First, the "To Do" approach leads to, and even encourages, micro-management of the people working on the project. Micro-management is appropriate when you have slackers and nincompoops working for you, but few project teams are composed entirely of these losers. The majority of your project team members will not thrive under micromanagement. This style tends to encourage dependency on the project manager rather than independence where people are held responsible for their results. Second, PMs are consistently more effective when they hold people accountable for reaching measured achievements rather than completing a list of tasks. How often does it happen that people complete a list of tasks and achieve nothing? When we base our assignments and monitoring on well conceived and measurable achievements, no one loses sight of the desired end result.

T'hird, the "To Do" list approach is hard to maintain. People have to report on many tasks which decreases the odds of receiving accurate and timely status reports. The PM, with or without clerical support, has a great deal of data entry to do to input all this status data. Amid the pressure of on-going multiple projects, tracking can fall behind and may even be dropped because the amount of effort is too large. This may sound like a stupid and improbable situattion but it happens with alarming frequency, even on large and important projects. The logic is, "No one is looking at all that detail anyway, so why spend all that time to catch up?" As a general rule, we like to see the majority of assignments in a project plan have durations that are between 1 week and 8 weeks long. Coupled with this, we advocate weekly status reporting of hours worked, percentage complete and an estimate of the hours of work remaining to complete the assignment. This combination allows the project manager to maintain good control while placing the responsibility for achievements on the team members. Using the work breakdown structure (WBS) for cross-functional corporate projects, you have the opportunity to design a assignment and monitoring process. As part of our achievement-driven approach, we recommend breaking work down into "packets" of achievements for which you will hold people and teams accountable. Learn how to craft a WBS that makes your projects more successful by working with a PM mentor in our on-line courses.

Work Breakdown Structure (WBS)

Click Here to View Video on YouTube:

5-Steps to Project Success

Download this Free Video (Same as above) (9MB file)

RIGHT Click & Save Target As: "5-Steps to Project Success - Seriously_v1.1" You have permission to freely copy and distribute this video.

Introduction to the WBS

A Work Breakdown Structure is a results-oriented family tree that captures all the work of a project in an organized way. It is often portrayed graphically as a hierarchical tree, however, it can also be a tabular list of "element" categories and tasks or the indented

task list that appears in your Gantt chart schedule. As a very simple example, Figure 1 shows a WBS for a hypothetical banquet.

Figure 1

Large, complex projects are organized and comprehended by breaking them into progressively smaller pieces until they are a collection of defined "work packages" that may include a number of tasks. A $1,000,000,000 project is simply a lot of $50,000 projects joined together. The Work Breakdown Structure (WBS) is used to provide the framework for organizing and managing the work. In planning a project, it is normal to find oneself momentarily overwhelmed and confused, when one begins to grasp the details and scope of even a modest size project. This results from one person trying to understand the details of work that will be performed by a number of people over a period of time. The way to get beyond being

overwhelmed and confused is to to break the project into pieces, organize the pieces in a logical way using a WBS, and then get help from the rest of your project team. The psychologists say our brains can normally comprehend around 7-9 items simultaneously. A project with thousands or even dozens of tasks goes way over our ability to grasp all at once. The solution is to divide and conquer. The WBS helps break thousands of tasks into chunks that we can understand and assimilate. Preparing and understanding a WBS for your project is a big step towards managing and mastering its inherent complexity. The WBS is commonly used at the beginning of a project for defining project scope, organizing Gantt schedules and estimating costs. It lives on, throughout the project, in the project schedule and often is the main path for reporting project costs. On larger projects, the WBS may be used throughout the project to identify and track work packages, to organize data for Earned Value Management (EVM) reporting, for tracking deliverables, etc.

History of the WBS

The WBS was initially developed by the U.S. defense establishment, and it is described in Military Standard (MIL-STD) 881B (25 Mar 93) as follows: "A work breakdown structure is a product-oriented family tree composed of hardware, software, services, data and facilities .... [it] displays and defines the product(s) to be developed and/or produced and relates the elements of work to be accomplished to each other and to the end product(s)." It requires some mental discipline to develop a product-oriented or deliverable-oriented grouping of project elements adding up to comprise the entire project scope. Intuitively, we tend to start out with a task-oriented approach. This is OK for very small projects where extensive project management controls will not be used. The task-oriented approach is easy to understand, because we can easily think of projects as collection of tasks. A task-oriented WBS can be developed by beginning with a simple "to-do" list and then clustering the items in a logical way. The logical theme could be project phases, functional areas, or major end-products. If your organization will be collecting historical data to form a cost database, you should try to select a standard approach consistent with the organizations long term data collection needs. A sample WBS is shown in the figure below:

WBS Format for System Development Projects

Additional level 2 elements not shown here might include development environment support, logistics and training, and installation and startup. This next link will take you to a skeleton sample WBS for a software and hardware system development project, and you can also download a zipped version of the corresponding MS-Project 2002 (.mpp) file. A WBS for a large project will have multiple levels of detail, and the lowest WBS element will be linked to functional area cost accounts that are made up of individual work packages. Whether you need three levels or seven, work packages should add up through each WBS level to form the project total.

Product or Process Oriented?

The WBS was initially defined as a product oriented family tree, however subsequent definitions have introduced more flexibility -- so a WBS can also be deliverable or process oriented. Your WBS can be built on nouns or verbs. If the results of your project are primarily verbs, then a verb based or process based WBS may make more sense. If your WBS is to be product or deliverable oriented, then you can start by thinking of the WBS as a parts list for the ultimate end-items of your project. This link will give a simple illustration of a product or process based WBS orientation. These differences are not shown to tell you what is the right way for your project, but just to familiarize you with the distinctions, so you can think about them and choose what's best for your project.

WBS Numbering

WBS elements are usually numbered, and the numbering system may be arranged any way you choose. The conventional numbering system is shown in the figure. The shaded box shown in the above slide could be numbered 1.2.2.3, which would tell you it was in the second box in level 2, the second box in level 3, and the third box in level 4.

WBS Dictionary
If a WBS is extensive and if the category content is not obvious to the project team members, it may be useful to write a WBS dictionary. The WBS dictionary describes what is in each WBS element, and it may also say what is not in an element, if that is unclear. Here is a sample of a WBS dictionary description: WBS Element 1.5.4.5. - Systems Integration Test Equipment Planning - This element includes the effort to identify requirements and specify types and quantities of test equipment needed to support the System Integration and Test process. It does not include the design or procurement of such equipment, which is covered in Element 1.5.4.6.

Mapping WBS for Cost Management

In

a product-oriented WBS, functional categories of work may form "cost accounts" within a WBS element. Cost account managers are responsible for a functional areas contribution to a WBS element. Cost accounts from several departments or functions may combine into one WBS element. Internal department planning for a cost account will be made up of individual work packages. A work package will typically have its own budget and schedule. Work packages should be small enough to be executed by individuals or small groups in a single department, and they should be of relatively short schedule duration. A small project might define a maximum work package size as two weeks of effort. Larger projects will assemble larger work packages that can be appropriately managed and controlled. The project manager will have to decide to what degree employment of various details of WBS implementation will benefit the efficient management of the project. On a very small project, a formal WBS may serve no useful purpose, but it can become valuable if project size or complexity start to increase. As an organizations project management environment matures, or as larger size and complexity are encountered, application of the WBS concept can evolve from an ad hoc list of tasks, to time-phased activity lists, task lists clustered by project deliverables and services, or an end-product focused WBS fed by cost accounts and work packages.

If you are using MS-Project or a similar project management software application, you may encounter the WBS as a vertical list with indents to show structure. This will be compatible with the Gantt View data entry screens. While some software packages provide a separate WBS view, you could prepare your WBS in the vertical format using a word processor, and then cut and paste your WBS into your project management software package.

Program and Contract WBSs

A top-level WBS for a large program is sometimes called a Program WBS (PWBS) or Program Summary WBS (PSWBS). If a project involves several organizational participants or contractors, guidance for one contractor can be provided in a Contract WBS (CWBS). The project manager may provide a high-level CWBS for each developer, perhaps to level 2 or level 3. The developer will then fill in the details of lower WBS levels to reflect the work to be accomplished and the data flow in that organization.

Organizational Standards
Your organization may want to decide on a standard WBS format or group of formats, use these across all projects, and communicate definitions widely so everyone will be speaking the same language. This can save re-learning project lessons and can lay the groundwork for successful data gathering to aid future cost estimates.

WBS Implementation
When you set up a project WBS, think about how you will be using it later in the project. Try to consider how you will organize the WBS, schedule format, manager assignments, and charge numbers, in your early project planning. These days, the WBS in smaller projects ends up automatically being the indent structure in your Gantt schedule, so pay attention to those indents, and make sure that is the WBS you want for rolling up costs in

your project, especially if you will be using EVM. It will be helpful if you can map the charge numbers, managers, and task groups to each other. This will help you track costs and progress for each manager. If your project schedule will on MS-Project, you may want to insert "text" columns into your schedule (Gantt View) for project charge numbers and manager names. If your project charge numbers cannot be linked to groups of tasks assigned to specific managers, you will have no way to provide performance measurement feedback to managers. Some project management environments have definite conventions for grouping items in a WBS. The best method is to have a WBS that works for your particular project environment. The WBS should be designed with consideration for its eventual uses. Your WBS design should try to achieve certain goals:

Be compatible with how the work will be done and how costs and schedules will be managed, Give visibility to important or risky work efforts, Allow mapping of requirements, plans, testing, and deliverables, Foster clear ownership by managers and task leaders, Provide data for performance measurement and historical databases, and Make sense to the workers and accountants.

There are usually many ways to design a WBS for a particular project, and there are sometimes as many views as people in the process. Experience teaches that everyone takes a slightly different slice of the apple, so make sure WBS arguments seeking metaphysical certainty are quickly brought to closure. Simple practicality combined with enlightened trial and error usually is the best approach.

Generating a WBS from Microsoft Project

There is a third-party add-on software application for MS-Project called WBS Chart Pro that will convert your Gantt chart task list with indents into a standard WBS graphic in a few clicks. You can also use this application to create a WBS and transfer it back MSP. I have found this software very valuable in organizing project work into a WBS, reviewing the scope of proposed projects, and helping managers visualize the WBS implicit in their MS-Project schedules.

PMI Practice Guide for WBS

The Project Management Institute (PMI) has a document, Project Management Institute Practice Standard for Work Breakdown Structures, that provides examples of WBS formats commonly used in several different project areas, construction, defense, etc. From the PMI Web site, upper right corner, click on Publications & Information Resources, then on Bookstore. Key word search for Work Breakdown Structure will bring up this standard and other references.

Timeboxing
October 19th, 2004 by Steve Pavlina Email this article to a friend

Timeboxing is a simple time management technique I use often. I first learned about it in software development terms. Lets say you have a fixed deadline for a new product you need to release, such as an annual upgrade to software for calculating income taxes. You must have a new version ready by a certain date. So youll probably use timeboxing for your development cycle, meaning that you do the best job you can within the time available. What new features you can implement are totally determined by the time frame. Slipping the schedule is simply not an option, so if you get behind, you must cut features. In terms of managing your own tasks, timeboxing can be a helpful technique. I primarily use it in two different ways. First, lets say you want to get something done, but theres a risk it could end up taking far more time than its worth because its the kind of task where you might exhibit perfectionist tendencies. So you give yourself a specific amount of time, which you wont go over, and you simpy do the best job you can within that time. As an example I use timeboxing when doing my Christmas shopping each year. I usually allocate a total of 2 hours to the task, which for me involves buying gifts for 8 people (my wife handles the rest). I decide in advance what kind of gift I should get each person on my list, and then I order as much as I can online and then head off to the local mall, where I zoom from one store to the next picking up gifts as I go. I also usually take advantage of my flexible schedule, doing the shopping on a weekday morning when the stores arent busy and I dont have to wait in line. So Im in and out with everyones gifts in under two hours. (I know some people love holiday shopping, and taking multiple trips to browse is fine if its something you enjoy. But if youre shopping-challenged like me, and youre no more likely to get gifts that are any better if you invest an extra 10 hours in the task, then it may be best to simply resign yourself to doing the best job you can within the time you have available.) The second way I use timeboxing is when I have a task or project that I wish to complete, but I dont really know where to begin, or it seems like its going to be a long time before I can finish a meaningful chunk. Or maybe its something I find really tedious and would have a tendency to procrastinate on. Then I use timeboxing to simply commit to working on the task for a given period of time to make a dent in it. I normally use a period in the range of 30-120 minutes. I release any concern about reaching a particular milestone within that time I simply commit to putting in the time, regardless of how far I get. An

example where I use this approach would be when Im writing a new article. Finishing a complete article will usually take me 3-8 hours. Sometimes I can complete an article in a single stretch, but most of the time Ill stretch it over multiple sessions. So I use timeboxing to just put a dent in the article and get started, committing myself to writing for 1-2 hours without worrying about how far I get. Then I just repeat the process until the work is complete. A side effect of this last method is that Ill often end up working much longer than I originally intended. If I commit to working on a tedious task for just 30 minutes, its easy to get started because Ive given myself permission to stop after only 30 minutes. But once Ive overcome that inertia and am now focused on the task, 90 minutes may pass before I even feel the desire to stop. Timeboxings ability to circumvent perfectionism and avoid procrastination makes it a useful time management technique. I even used it for this blog entry, and now that my wife has returned home with dinner and a movie rental, its time to say goodbye.

Email this article to a friend If you've found this website helpful, please donate to show your support. The average donation is $20.71 (updated April 2011).

Related Articles Personal Quotas Best of StevePavlina.com Productivity 101 33 Rules to Boost Your Productivity The 50-30-20 Rule The Joy of Solving Problems How to Make More Intelligent Info Product Purchases 10 Tips for College Students

This entry was posted on Tuesday, October 19th, 2004 at 6:22 pm and is filed under Getting Things Done, Productivity, Time Management. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

11 Responses to Timeboxing

1. Roger Jack Says:

October 19th, 2004 at 7:10 pm

I have had success with both forms of timeboxing, especially the second form. Sometimes I commit to working on something for just 15 minutes that I dont really want to work on. At the end of 15 minutes, Im often becoming more interested in the task and I may keep working on it. 2. cliffski Says:
October 21st, 2004 at 8:25 am

wow this definitely works. it actually motivated me enough to do a proper schedule for my current game, and jeez there is a lot to do. 3. GBGames Says:
October 21st, 2004 at 11:04 am

Time boxing is one of those hard-to-google items. Prime-time boxing comes up more of then than not. Whats interesting is that this description seems a bit different from what you can find elsewhere. The idea here is Get something/anything done within a period of time whereas the other descriptions Ive found make it seem like time boxing says Get specific things done in this time. Then again, it could be because those descriptions are for time boxing over longer periods of time. The idea is probably release software within 6 months with two month milestones, no matter what features are ready by then as opposed to this article which seems more like heres your deadline. Do something with your time! 4. Dmitry Chestnykh Says:
February 7th, 2005 at 9:00 am

It just works! Thanks! 5. Fry Crayola Says:

March 15th, 2005 at 6:26 am

Having just read this article (and the related one), I realised that Id actually been using Timeboxing myself in my own way. For the last few years I had been studying at university. Come the crunch time of exam revision, it wa clear that I needed to do some work for an exam that may have been a week or two later. Always safer to start early yet hard to convince myself to do. I hated studying. Heck, I still do.

So I went to the shop, and bought myself a nice big bottle of chocolate milk (Im just a big kid). I stuck it in the fridge, and promised myself I could have it if I work for an hour. I did this a lot. If I didnt work for the hour, I couldnt have the milk (and if I did have it, it tasted of pure guilt). If I did the work, whatever the achievement, I got the milk and it felt good. It becomes a part of my work ethic now. If I reward myself in small doses at regular intervals, I get a lot more done. 6. neon Says:
March 15th, 2005 at 9:37 am

Fry Carola I think, Steves answer would be: Have your purpose as your chocolate milk. 7. Beck from Australia Says:
April 13th, 2005 at 7:30 pm

This is wonderful! All I needed to get started on the 3 essays I have due next week was a hint on planning, motivation and overcoming procrastination (I got here via your procrastination article)Ive got you bookmarked thank you! Beck 8. Eleanor Says:
April 22nd, 2005 at 10:19 pm

im a high school student from australia, and i find myself procratinating a lot. i have often tried to overcome this, with no success at all. All my assessment tasks are completed at the very last minute and i make myself work through the task throughout the night. By doing this, i have found out that i also suffer memory loss. On several occasions i have said to myself ive got to start seeking professional help and today, i finally came about to search the net for causes of procrastination and how to resolve it. i came across the article you wrote and i found it very interesting. i always thought that if i could find a secluded place, i could concentrate more on my work. i still havent found a way to overcome procrastination but after reading your article it had helped me alot. i have found myself some motivation and will follow your advice

Thank you very much 9. Clive Crous Says:

May 9th, 2005 at 2:44 am

Great articles. Ive been looking for a solution to this affliction of mine for quite some time. This looks like a great way to start Thanks 10. katherine Says:
June 3rd, 2005 at 11:44 pm

I am going to try this! 11. Jasmine Says:

August 26th, 2005 at 7:48 am

Thanks Steve!!! i found your article is very uplifting and your piece of writing style is very different from others!!! Good ones! ive shared ur website with my siblings and my friends. Its really nice of you to share your experience and knowlegde with us!!! Procrastination i cant find any good books about it yet but your writing are in such an organized way and clearly brought out the points. its pretty easy to understand especially for those who has sufferred from it! Once again, thanks!

Free Personal Development Insights Newsletter

Get Steve's Free Newsletter Sign up below to receive my free email newsletter, which I usually send out once or twice a month. You can unsubscribe at any time, and I won't share your contact info with anyone else. With tens of thousands of active subscribers, this is one of the most popular personal development newsletters in the world, with insightful and motivating content to help you grow faster.
Name:

Email:

art

Gantt Chart

During the era of scientific management, Henry Gantt developed a tool for displaying the progression of a project in the form of a specialized chart. An early application was the tracking of the progress of ship building projects. Today, Gantt's scheduling tool takes the form of a horizontal bar graph and is known as a Gantt chart, a basic sample of which is shown below: Gantt Chart Format Task 1 2 3 4 5 6 Duration Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2 mo. 2 mo. 2 mo. 2 mo. 2 mo. 2 mo.

The horizontal axis of the Gantt chart is a time scale, expressed either in absolute time or in relative time referenced to the beginning of the project. The time resolution depends on the project - the time unit typically is in weeks or months. Rows of bars in the chart show the beginning and ending dates of the individual tasks in the project. In the above example, each task is shown to begin when the task above it completes. However, the bars may overlap in cases where a task can begin before the completion of another, and there may be several tasks performed in parallel. For such cases, the Gantt chart is quite useful for communicating the timing of the various tasks. For larger projects, the tasks can be broken into subtasks having their own Gantt charts to maintain readability. Gantt Chart Enhancements This basic version of the Gantt chart often is enhanced to communicate more information.

A vertical marker can used to mark the present point in time. The progression of each activity may be shown by shading the bar as progress is made, allowing the status of each activity to be known with just a glance. Dependencies can be depicted using link lines or color codes.

Resource allocation can be specified for each task. Milestones can be shown.

Gantt Chart Role in Project Planning For larger projects, a work breakdown structure would be developed to identify the tasks before constructing a Gantt chart. For smaller projects, the Gantt chart itself may used to identify the tasks. The strength of the Gantt chart is its ability to display the status of each activity at a glance. While often generated using project management software, it is easy to construct using a spreadsheet, and often appears in simple ascii formatting in e-mails among managers. For sequencing and critical path analysis, network models such as CPM or PERT are more powerful for dealing with dependencies and project completion time. Even when network models are used, the Gantt chart often is used as a reporting tool. Alternative spellings: The name of this tool frequently is misspelled as "Gannt Chart". Operations > Gantt Chart The project scope management knowledge area is defined by the processes that limit and control the work included in a project. These processes ensure that all the work of the project is included. Processes in this knowledge area include the initiation process as well as all the processes related to the scoping of the project. Each process has a set of input and a set of output. Each process also has a set of tools and techniques used to convert input into output.

Initiation

Process Group: Initiating Input includes: product description; strategic plan; project selection criteria; historical information Methods used: project selection methods and expert judgment from other units within the organization; consultants; industry groups; or professional / technical associations. Output includes: scope statement; supporting detail, scope management plan, project charter, identified project manager, constraints, and assumptions. Committing the organization to begin the next phase of the project. The process of formally recognizing that a new project exists or that an existing project should continue to its next phase.

Scope Planning

Process Group: Planning Input includes: the product description; project charter; constraints, and assumptions. Methods used: product analysis; benefit / cost analysis; identifying alternatives, and expert judgment. Output includes: scope statement; supporting detail, and scope management plan The process of developing a written scope statement as the basis for future project decisions. The scope statement forms the basis for an agreement between the project team and the project customer by identifying the project objectives and major project deliverables.

Scope Definition

Process Group: Planning Input includes: scope statement; constraints; assumptions; and historical information. Methods used: work breakdown structure templates (or WBS from a previous project) and decomposition (subdivision). Output includes: work breakdown structure The process of subdividing the major project deliverables into smaller, more manageable components.

Scope Verification

Process Group: Controlling Input includes: work results (completed or partially completed deliverables, incurred or committed costs, etc.), and product documentation (plans, specifications, technical documentation, etc.) Methods used: inspection (measuring, examining, reviewing and testing to determine if results conform to requirements) Output includes: formal acceptance The process of formally accepting the project scope by the stakeholders (sponsor, client, customer, etc.)

Scope Change Control

Process Group: Controlling Input includes: WBS, performance reports, change requests, and the scope management plan. Methods used: a scope change control system; performance measurement techniques; and additional planning. Output includes: scope changes; corrective action, and lessons learned. The process of controlling changes to project scope.

Welcome to Project Staffing Company! PSC is a full-service staffing company performing business and technology consulting, and professional services, and providing highly qualified and experienced specialists for your projects worldwide. We are dedicated to creating unique experience and remarkable customer satisfaction for all our customers, big and small, throughout the commitment and dedication of our every consultant.

Do you have an ongoing project? Is its completion critical for your business? Do you need to meet a deadline? Don't have all the necessary resources? Or you can't find valuable resources in your area? We can help you. Our staff is there to serve you. We employ only the best. Our people are recognized specialists in their fields. We can provide you with a team of most reliable people whose number one mission is to help you succeed.

Or maybe you can't afford to hire the entire team full time? Did you recently have a layoff and now it impedes your operations? Do your existing customers require a support you can no longer provide? We can help you there too. We offer you our services at highly competitive rates.

Why PSC?

Highly skilled, well trained, most qualified and experienced, field tested personnel Thorough candidate screening and continuous performance monitoring Nearly two decades of experience and global presence Strong methodology and high quality commitment behind every project we take on

 Professionalism and customer satisfaction at competitive rates Professional Services On Demand SM

The CASE Repository: More than another database application

Richard J. Welke, Ph.D. (c) Meta Systems, Ltd. October 7, 1988 Download article (255 KB PDF) - available again after many years! Many of the fundamental differences between today's Language Workbenches can be attributed to their different meta-metamodels: the set of concepts they offer language designers. This article explains the benefits, problems and differences between the main meta-metamodels, which are still in use today: Eclipse's Ecore (EAR), Microsoft's DSL Tools (OPRR without n-ary relationships), and MetaEdit+'s GOPPRR (WOPRR extended with ports).

Background
The keynote "The Model Repository: More than just XML under version control" by Steven Kelly at the 2008 OOPSLA Workshop on DSM paid homage to this article. Dr. Welke has given his kind permission for the original article to be made available here. The version available here was scanned and OCR'd from a photocopy of the full white paper from Meta Systems. Several versions of the article were published; the first below was the most comprehensive and closest to the original white paper, the last is the most widely quoted. Welke, R.J.: "The CASE Repository: More than another database application," Proceedings of 1988 INTEC Symposium Systems Analysis and Design: A Research Strategy, Atlanta, Georgia, Cotterman, W.W. and J.A. Senn (eds.), Georgia State University, 1988. Welke, R.J.: "Meta Systems on Meta Models," C/A/S/E Outlook, 1989, Vol.4 (December 1989), pp. 35-44. Welke, R.J.: "CASE Repositories: More than another DBMS Application," Challenges and Strategies for Research in Systems Development, Cotterman, W. and J. Senn (eds.), J. Wiley, Chichester, UK, 1992, pp. 181-214.

Terminology
Readers today may be confused by some of the terminology: Welke was often inventing both the concepts and the terminology, and whilst concepts are valid in any time, the terminology we use today has taken a different route. Welke's terminology is described on page 3; what he calls a meta-model is nowadays more commonly referred to as a meta-metamodel; what he calls a meta-schema is nowadays referred to as a metamodel.

Original Abstract
There is increased awareness within the CASE (Computer-Aided Software Engineering) arena, of the need for a central Repository of system description information. This is brought on by a growing recognition that only with a strong central repository, can CASE tool sets be integrated, cope with large projects, provide full life-cycle support, produce complete documentation, perform system-wide validation and verification, and adequately control a project. In examining the various approaches chosen or proposed by various vendors it is apparent that, for many users and providers, a CASE Repository is nothing more than an off-the-shelf database management system into which specification information is directly placed. However, as this paper will demonstrate, commercially available database systems cannot be directly employed as a CASE repository.

Author Bio
Dr. Welke is Director of the Center for Process Innovation, professor and previous chairman of the CIS department at Georgia State University. Prior professorships include appointments in the Netherlands (TU-Delft as Cor Wit Research Professor, Erasmus/RSM as HL, Business Informatics) and Canada (McMaster University). Dr. Welke was co-founder of the information systems discipline's now-major academic organizations, (ICIS, AIS, TIMS College on IS, and IFIP WG 8.2). He has been the ICIS program chair (1986) and co-conference chair (1996) as well as serving on its executive committee. He has started, owned and managed two Computer-aided Software Engineering (CASE) companies; one in Canada (Methodsworks) and the other in the US (Meta Systems).

Risk Management
Risk Manager Careers
By Mark Kolakowski, About.com Guide See More About:

financial jobs risk compliance securities traders

Risk Management Career Overview: Within the financial services industry, risk management involves assessing and quantifying business risks, then taking measures to control or reduce them. Risk management often is part of the compliance function, but also may be part of specific business units, such as securities trading desks or loan origination departments. Education: To work in risk management, a bachelor's degree is the bare minimum, and often an MBA also is required. Strong quantitative skills are a must, and thus a background in management science and in the development or use of predictive models can be very helpful. Certification: There are several formal risk management certifications. They are required by a growing number of employers, and may help start or advance a career in the field with other firms, but a majority of companies do not yet demand them. In any case, experience in law, accounting, compliance, insurance and/or operational areas of the financial services industry are important credentials. For example, risk managers who oversee securities trading should have intimate knowledge of trading practices and procedures, knowledge that is best gained from prior experience as a trader or as a trading desk assistant. Duties and Responsibilities: Risk management is concerned with identifying and measuring the risks faced by the firm. Risk managers either may be generalists who cover several different areas, or specialists who concentrate on a single one. Within the financial services industry, the major categories of risk include, but are not limited to:

Defaults on loans extended by the firm Losses on securities inventories held by traders Losses on investment securities held for the firms own account Counter party risk (another financial firm failing in its obligations to yours)

Risk management personnel develop, implement and enforce rules and procedures designed to mitigate these risks. For example, the value of inventory held by a securities trader might be strictly limited. Risk management personnel also employ various financial instruments and contracts to control risks, such as:

Insurance Swaps Derivatives Futures contracts

Options contracts

Typical Schedule: The time commitment is highly variable, dependent on the firm and the position. Since risk management is a vital function, risk managers can expect to put in workweeks that far exceed 40 hours. Moreover, during periods of high market turbulence and financial uncertainty, risk management personnel may be constantly on call. What's to Like: Risk management is a crucial function, and thus has a great deal of intrinsic job satisfaction. Additionally, positions in this field are well-paid and wellrespected. The work can be fast-paced and stimulating. What's Not to Like: The flipside of working in such a critical field is that the demands of the job can become overwhelming in turbulent periods for the industry or the firm, when weighty decisions may have to be made on a moment's notice. Also, the "policeman" aspect of risk management can create an unpleasant adversarial relationship with some categories of producers, especially securities traders. Moreover, the psychology of power is such that influential people in the firm, such as members of executive management, are likely to resist playing by the rules. Salary Range: The Bureau of Labor Statistics combines risk managers with other categories of financial managers. As of May 2006, the median annual salary for all financial managers was $91,000 and the top 10% earned over $132,000. Within the financial services industry, however, the median salaries for risk managers can exceed $132,000. Home > documentation

documentation

Instructions for using a computer device or program. Documentation can appear in a variety of forms, the most common being manuals. When you buy a computer product (hardware or software), it almost always comes with one or more manuals that describe how to install and operate the product. In addition, many software products include an online version of the documentation that you can display on your screen or print out on a printer. A special type of online documentation is a help system , which has the documentation embedded into the program. Help systems are often called contextsensitive because they display different information depending on the user's position (context) in the application.

Documentation is often divided into the following categories: installation: Describes how to install a program or device but not how to use it. reference: Detailed descriptions of particular items presented in alphabetical order. Reference documentation is designed for people who are already somewhat familiar with the product but need reminders or very specific information about a particular topic. tutorial: Teaches a user how to use the product. Tutorials move at a slower pace than reference manuals and generally contain less detail. A frequent lament from computer users is that their documentation is inscrutable. Fortunately, this situation is improving, thanks largely to advances in help systems and online tutorials. These forms of documentation make it much easier to deliver the specific information a user needs when he or she needs it.