What is PRINCE2

PRINCE2 (an acronym for PRojects IN Controlled Environments) is a de facto process-based method for effective project management.

Used extensively by the UK Government, PRINCE2 is also widely recognised and used in the private sector, both in the UK and internationally. The PRINCE2 method is in the public domain, and offers non-proprietorial best practice guidance on project management. 

The key features of PRINCE2 are a:

• focus on business justification
• defined organisation structure for the project management team
• product-based planning approach
• emphasis on dividing the project into manageable and controllable stages
• flexibility that can be applied at a level appropriate to the project.

Using PRINCE2 provides you with greater control of resources, and the ability to manage business and project risk more effectively. This will benefit:

• individuals seeking leading project management skills and greater employment prospects
• project managers
• directors/executives (senior responsible owners) of projects, and
• organisations

For individuals, PRINCE2 certification is an invaluable asset to your career as it increases employment prospects and helps you to do your job more effectively.
For organisations, PRINCE2's formal recognition of responsibilities within a project, together with its focus on what a project is to deliver (the why, when and for whom) provides your organisation's projects with:

• a common, consistent approach
• a controlled and organised start, middle and end
• regular reviews of progress against plan
• assurance that the project continues to have a business justification

PRINCE2 - A Structured Project Management Methodology

PRINCE2 (PRojects IN Controlled Environments) is a process-based method for effective project management. PRINCE2 is a de facto standard used extensively by the UK Government and is widely recognised and used in the private sector, both in the UK and internationally.

Structured project management means managing the project in a logical, organised way, following defined steps. A structured project management method like PRINCE2 is the written description of this logical, organised approach.
We know from experience that projects which aren't organised and controlled properly usually go disastrously wrong. Some of the big ones hit the press.
London Ambulance and Channel Tunnel, for example, both experienced very public problems of systems not working properly and huge overspends. Structured project management methods have been developed to try to prevent such disasters.
The PRINCE2 Methodology says that a project should have:

• An organised and controlled start
  ie. organise and plan things properly before leaping in;
• An organised and controlled middle
  ie. when the project has started, make sure it continues to be organised and controlled;
• An organised and controlled end
  ie. when you've got what you want and the project has finished, tidy up the loose ends.

In order to describe what a project should do and when, PRINCE2 has a series of processes which cover all the activities needed on a project, from starting up to closing down.

PRINCE2 Project Management Roles

Project Manager

Organising and controlling a project means that we need to have someone responsible for doing the organising and controlling. This person is called the Project Manager.
The Project Manager will select people to do the work on the project and will be responsible for making sure the work is done properly and on time.
The Project Manager draws up the Project Plans that describe what the project team will actually be doing and when they expect to finish.

Customer, User and Supplier

The person who is paying for the project is called the customer or executive.
The person who is going to use the results or outcome of the project, or who will be impacted by the outcome of a project, is called the user.
On some projects, the customer and user may be the same person. The person who provides the expertise to do the actual work on the project (ie. will be designing and building the outcome) is called the supplier or specialist.
All of these people need to be organised and co-ordinated so that the project delivers the required outcome within budget, on time and to the appropriate quality.

Project Board

Each PRINCE2 project will have a Project Board made up of the customer (or executive), someone representing the user side, and someone representing the supplier or specialist input.
In PRINCE2, these people are called Customer, Senior User and Senior Supplier respectively.
The Project Manager reports regularly to the Project Board, keeping them informed of progress and highlighting any problems he/she can foresee.
The Project Board is responsible for providing the Project Manager with the necessary decisions for the project to proceed and to overcome any problems.

PRINCE2 Project Management Techniques

Project Assurance

Providing an independent view of how the project is progressing is the job of Project Assurance. In PRINCE2, there are three views of assurance: business, user and specialist. Each view reflects the interests of the three Project Board members.
Assurance is about checking that the project remains viable in terms of costs and benefits (business assurance), checking that the users' requirements are being met (user assurance), and that the project is delivering a suitable solution (specialist or technical assurance). On some projects, the assurance is done by a separate team of people called the Project Assurance Team, but the assurance job can be done by the individual members of the Project Board themselves.

Project Support

On most projects there is a lot of administrative work needed: keeping everyone informed, arranging meetings, keeping plans up-to-date, chasing things up, keeping files, etc. Project Managers often do all this work themselves, particularly on smaller projects, but if there are a number of projects going on at the same time a Project Support Office can be setup to help the Project Managers with this work.

PRINCE2 Scope

In today's projects, there are often different groups of people involved, including the customer, one or more suppliers, and of course the user. PRINCE2 is designed to provide a common language across all the interested parties. Bringing customers and suppliers together generally involves contracts and contract management. Although these aspects are outside of PRINCE2, the method recognises the need to provide projects with the necessary controls and breakpoints to work successfully within a contractual framework.

Controlling Change

Apart from describing the different people involved on a PRINCE2 project, and what they are each responsible for, the method also explains how to manage risk, how to manage quality, and how to control change on the project. Risk Management is about working out what could go wrong and planning what to do if it does. Quality Management is about checking the quality of work done on the project, either by testing it or reviewing the work in some way.
There are always lots of changes during the life of a project, people change their minds, other things happen which affect what the project is doing. PRINCE2 has a technique of controlling the way changes impact the project in order to prevent the project going off in the wrong direction.
So, PRINCE2 is a method for managing projects. It helps you work out who should be involved and what they will be responsible for. It gives you a set of processes to work through and explains what information you should be gathering along the way. But PRINCE2 doesn't do the work for you, it cannot guarantee that your projects will be successful. Good projects, which deliver quality results, on-time and within budget are dependent on the quality of people involved from Project Board down to individual team members.
Having read this brief introduction to project management and PRINCE2, the next thing to do is go on a training course and find out more!

PRINCE2 Processes - The PRINCE2 Process Model

PRINCE2 is a process-based approach for project management providing an easily tailored, and scaleable method for the management of all types of projects.
Each process is defined with its key inputs and outputs together with the specific objectives to be achieved and activities to be carried out.

Directing a Project

Directing a Project runs from the start-up of the project until its closure. This process is aimed at the Project Board. The Project Board manages and monitors via reports and controls through a number of decision points.
The key processes for the Project Board break into four main areas:

• Initiation (starting the project off on the right foot)
• Stage boundaries (commitment of more resources after checking results so far)
• Ad hoc direction (monitoring progress, providing advice and guidance, reacting to exception situations)
• Project closure (confirming the project outcome and controlled close).
• This process does not cover the day-to-day activities of the Project Manager.

Starting up a Project

This is the first process in PRINCE2. It is a pre-project process, designed to ensure that the pre-requisites for initiating the project are in place.
The process expects the existence of a Project Mandate which defines in high level terms the reason for the project and what outcome is sought. Starting up a Project should be very short.
The work of the process is built around the production of three elements:

• Ensuring that the information required for the project team is available
• Designing and appointing the Project Management Team
• Creating the Initiation Stage Plan.

Initiating a Project

The objectives of Initiating a Project are to:

• Agree whether or not there is sufficient justification to proceed with the project
• Establish a stable management basis on which to proceed
• Document and confirm that an acceptable Business Case exists for the project
• Ensure a firm and accepted Foundation to the project prior to commencement of the work
• Agree to the commitment of resources for the first stage of the project
• Enable and encourage the Project Board to take ownership of the project
• Provide the baseline for the decision-making processes required during the project's life
• Ensure that the investment of time and effort required by the project is made wisely, taking account of the risks to the project.

Managing Stage Boundaries

This process provides the Project Board with key decision points on whether to continue with the project or not.
The objectives of the process are to:

• Assure the Project Board that all deliverables planned in the current Stage Plan have been completed as defined
• Provide the information needed for the Project Board to assess the continuing viability of the project
• Provide the Project Board with information needed to approve the current stage's completion and authorise the start of the next stage, together with its delegated tolerance level
• Record any measurements or lessons which can help later stages of this project and/or other projects.

Controlling a Stage

This process describes the monitoring and control activities of the Project Manager involved in ensuring that a stage stays on course and reacts to unexpected events. The process forms the core of the Project Manager's effort on the project, being the process which handles day-to-day management of the project.
Throughout a stage there will be a cycle consisting of:

• Authorising work to be done
• Gathering progress information about that work
• Watching for changes
• Reviewing the situation
• Reporting
• Taking any necessary corrective action.

This process covers these activities, together with the on-going work of risk management and change control.

Managing Product Delivery

The objective of this process is to ensure that planned products are created and delivered by:

• Making certain that work on products allocated to the team is effectively authorised and agreed accepting and checking Work Packages
• Ensuring that work conforms to the requirements of interfaces identified in the Work Package
• Ensuring that the work is done
• Assessing work progress and forecasts regularly
• Ensuring that completed products meet quality criteria
• Obtaining approval for the completed products.

Closing a Project

The purpose of this process is to execute a controlled close to the project.
The process covers the Project Manager's work to wrap up the project either at its end or at premature close.
Most of the work is to prepare input to the Project Board to obtain its confirmation that the project may close.
The objectives of Closing a Project are therefore to:

• Check the extent to which the objectives or aims set out in the Project Initiation Document (PID) have been met
• Confirm the extent of the fulfilment of the Project Initiation Document (PID) and the Customer's satisfaction with the deliverables
• Obtain formal acceptance of the deliverables
• Ensure to what extent all expected products have been handed over and accepted by the Customer
• Confirm that maintenance and operation arrangements are in place (where appropriate)
• Make any recommendations for follow-on actions
• Capture lessons resulting from the project and complete the Lessons Learned Report
• Prepare an End Project Report
• Notify the host organisation of the intention to disband the project organisation and resources.

Planning

PRINCE2 recommends three levels of plan to reflect the needs of the different management levels involved in the project, stage and team.
Planning is a repeatable process and its activities are included within the seven main PRINCE2 processes, as appropriate. Information about plans and how to plan can be found in the Plans Theme section of the PRINCE2 Manual.

The activities of planning are :-

• Design the plan
  
• Define and analyse the products
  
• Identify the activities and dependencies
  
• Prepare estimates
  
• Prepare the schedule
  
• Analyse the risks
  
• Document the plan
  

PRINCE2 uses a technique known as ‘Product based planning’ which requires four activities :-

• Write the Project Product Description
  
• Create the product breakdown structure
  
• Write the product descriptions
  
• Create the product flow diagram
  

These four activities are performed within the ‘Define and analyse the products’ activity above.

The differences between QA and QC

Quality assurance (QA) refers to the planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled. It is the systematic measurement, comparison with a standard, monitoring of processes and an associated feedback loop that confers error prevention. This can be contrasted with Quality "Control". which is focused on process outputs.

Quality Assurance Is Not Quality Control
The difference is that QA (Quality Assurance) is process oriented and QC (Quality Control) is product oriented.

And Testing, therefore is product oriented and thus is in the QC domain. Testing for quality isn't assuring quality, it's controlling it. Moreover, Testing is The process of executing a system with the intent of finding defects. (Note that the "process of executing a system" includes test planning prior to the execution of the test cases.)

•     Quality Assurance makes sure you are doing the right things, the right way.
•     Quality Control makes sure the results of what you've done are what you expected.

Quality control is a set of “activities” that need to be performed in order to detect problems during production and before the product goes live. These activities ensure that final deliverable meets the specifications and quality standards set by the organization. QC often includes peer reviews, “testing”, code reviews etc.

In theory, quality control can be achieved with minimal testing. For example, a thorough review of source code and checks for known previously problems can reduce the possibility of defects and might be enough to meet the quality standards set by the organization. However still, in most cases, testing is the most important activity for quality control, but it is not the ‘only’ activity.

Quality control is extremely important for ensuring that applications are bug free and meet the specifications and requirements, but QC might not always be the most efficient ways of ensuring quality. This is where Quality Assurance plays its role. But it is a concept that is often misunderstood by even the most experienced professions.

The QA team's job is to see that standards, processes, and policies (or other governing/guiding "writ") are in place and carried out; to recommend and implement improvements to them, and to ensure that the people that need to know about them know about them. QA "audits" or "reviews" are intended to determine the efficacy of these "writs."

It's often easier to understand QA by an example: In one place (a large company with large projects), a QA's role supposedly to help project managers plan their projects - so that the projects follow certain organizational procedures; so that they include the required artifacts, events, and milestones; and so that the projects know what is expected of them and when in terms of reports, reviews, and documentation. As the project progressed, QA would conduct "checkpoints" along the way to see where the project may be developing risks, for example either by progressing beyond where they've got authorization to go, or where they may have need to escalate issues to management.

A Quality Assurance review would focus on the process elements of a project - e.g., are requirements being defined at the proper level of detail. In contrast, QC activities focus on finding defects in specific deliverables - e.g., are the defined requirements the right requirements. Testing is one example of a QC activity, but there are others such as inspections. Both QA and QC activities are generally required for successful software development.

Why would "assurance" mean process-related and "control" mean product-related?

Because "assurance" means that you know you did everything needed to make something that works right, while "control" means that you have no idea whether any or all of your batch o'junk is worth anything until you examine each item.

The need to test ("control") is a function of the circumstance of the existence of bugs or lack of confidence. Whereas 'assurance' is a passive term with a more universal connotation. The need to "assure" is a function of building confidence regardless of the existence of bugs and isn't just about bugs, but of the entire effort.

The difference between QA and QC is largely one of power and control. QC is usually as service provided to development (i.e. under the control of development) and is responsible for providing that service. QA expects development to provide services to it (control development) and is not responsible for any result.

The above statement is a symptom of one of the biggest problems in the entire software industry. People don't know what "QA" is supposed to do (as defined in this page). As a result many that do QA, do it wrongly, and many that work with those doing QA incorrectly wind up hating QA because of the lousy experience they had with it.

QA, when done effectively in a project, should not even cross paths with developers except perhaps at the highest levels of management. Or to teach new developers the organizational processes, or teach existing developers about changes to existing organizational processes. And then later QA may interact with development to figure out whether the processes work and what needs to happen to make sure they work better. QA should not be causing developers to do any more work than they need to be doing to develop the work.

Quality assurance makes sure the project will be completed based on the previously agreed specifications, standards and functionality required without defects and possible problems. It monitors and tries to improve the development process from the beginning of the project to ensure this. QA is involved in the project from the beginning. This helps the teams communicate and understand the problems and concerns, also gives time to set up the testing environment and configuration. On the other hand, actual testing starts after the test plans are written, reviewed and approved based on the design documentation.

Testing methods based on The box approach:
Black Box Testing
Black-box testing is a method of software testing that tests the functionality of an application as opposed to its internal structures or workings. Specific knowledge of the application's code/internal structure and programming knowledge in general is not required. The tester is only aware of what the software is supposed to do, but not how i.e. when he enters a certain input, he gets a certain output; without being aware of how the output was produced in the first place. Test cases are built around specifications and requirements, i.e., what the application is supposed to do. It uses external descriptions of the software, including specifications, requirements, and designs to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid inputs and determines the correct output. There is no knowledge of the test object's internal structure. This method of test can be applied to all levels of software testing: unit, integration, system and acceptance. It typically comprises most if not all testing at higher levels, but can also dominate unit testing as well.

White Box Testing
White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing). In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. While white-box testing can be applied at the unit, integration and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements.

Next table shows the differences between them.

QA	vs.		QC
Definition from ASQ.org Assurance: The act of giving confidence, the state of being certain or the act of making certain. QA: The planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled. Other definition QA is a failure prevention system that predicts almost everything about product safety, quality standards and legality that could possibly go wrong, and then takes steps to control and prevent flawed products or services from reaching the advanced stages of the supply chain.		Definition from ASQ.org Control: An evaluation to indicate needed corrective responses; the act of guiding a process in which variability is attributable to a constant system of chance causes. QC: The observation techniques and activities used to fulfill requirements for quality. Other definition QC is a failure detection system that uses a testing technique to identify errors or flaws in products and tests the end products at specified intervals, to ensure that the products or services meet the requirements as defined during the earlier process for QA.
QA department develops all the planning processes and procedures in order to try to make sure that the products manufactured or the service delivered by the organization will be of good quality.		As some process parameters cannot be controlled, QC department checks the products or services for defects that happen due to these parameters, trying to achieve the overall QC objective of providing a defect-free product or service to the customers.
QA defines the standards/methodology to be followed in order to meet the customer requirements. *		QC ensures that the defined standards are followed at every step.*
* This is done by conducting various tests and checks. Based on them, the QC prepares regular reports that act as an input to the QA department which then reviews the same and decides on the corrective and preventive actions required in the processes.
In general, the QA activities are done before the product is manufactured or the service delivered (proactive approach).		The QC activities are done during the manufacturing process and once the product is manufactured.
QA is process oriented.		QC is product oriented.
QA makes sure you are doing the right things, the right way.		QC makes sure the results of what you've done are what you expected.
QA tasks are conducted by managers, third party auditors, and customers. *		QC tasks are executed by experts who are directly involved with the design, or manufacture of a product on the shop floor such as engineers, inspectors, etc. *
* For this reason, one person cannot perform both activities (QA and QC) because will result in a conflict of interest.
Examples - A QA audit would focus on the process elements of a project. e.g.: Are requirements being defined at the proper level of detail? - Process documentation - Establishing standards - Developing checklists - Conducting internal audits		Examples - A QC review will focus on product elements. e.g.: Are the defined requirements the right requirements? - Performing inspections - Preforming testing
Example - QC detected a recurrent problem with the quality of the products. QC provides feedback to QA personnel that there is a problem in the process or system that is causing product quality problems. QA determines the root cause of the problem and then brings changes to the process to ensure that there are no quality issues in future.

I've also found some articles they wrote the comparison between QA and QC as follows:

Quality Assurance:
1. Quality assurance meant for developing, organizing the best quality process
2. QA is process related
3. QA focuses on building in quality and hence preventing defects
4. QA: Deals with process
5. QA: for entire life cycle
6. Quality Assurance makes sure you are doing the right things, the right way.
7. QA is preventive process.

Quality Control:
1. Quality control meant for implementing the process developed by former team
2. QC is the actual testing of the software
3. QC focuses on testing for quality and hence detecting defects
4. QC: Deals with product
5. QC: for testing part in SDLC
6. Quality Control makes sure the results of what you've done are what you expected
7. QC is corrective process.
 
As conclusion: 
Both departments are essential to maintain good quality of the deliverables.
And keep in mind no matter how you define QA and QC,  the goal is: to delivery good quality.

The top 10 fact reasons about why are many of IT project fail

The top 10 fact reasons about why are many of IT project fail:

1. There is a lack of user input: The project commences, people begin working diligently, but when the project is completed, the people wanted a horse and we built a camel. 
2. Incomplete requirements and specifications: We build a terrific solution and after we submit it for user testing, we are being told that it doesn't do half of the things they need and we were never told any of these requirements. Rebuild takes at least four months, and we miss project timeline and budget.
3. Changing requirements and specifications: Every two weeks during the project, a sales manager might would appear and ask for a new set of features to match something he read in a book yesterday. Ten scope changes and $500,000 later, the project misses badly and everyone in IT is blamed because he didn't make his sales numbers.
4. Lack of executive support: The project doesn't get the people or money it needs to proceed successfully because the project isn't seen as important by senior executives in the company.
5. Technology incompetence: To save a few dollars, parts of the project were outsourced to people who didn't understand the technologies we were using. When the first review of their components came in, the entire component had to be rebuilt from scratch.
6. Lack of resources: The project was very important, but cash and people were tight, so IT was told to fit it in around their regular schedules. In the end, the project collapsed for lack of focus.
7. Unrealistic expectations: The new sales application was designed to gather important information to save the company. But having a great sales tool wasn't going to do any good if the salespeople refused to use it and thus didn't provide the company the information they needed to stay ahead of the competition.
8. Unclear objectives: The new network upgrade worked perfectly, and all of the infrastructure was in place, but because the company was hoping to save money, not improve performance, they dismantled a perfectly working infrastructure and outsourced everything to an organization providing half the services to save a few dollars.
9. Unrealistic timeframes: The new customer-relationship management tool was critical to the long-term performance of the university, but only six months were allocated to get everything installed and working and get all the people switched over to the new system. Ninety percent of the potential benefits were lost due to the timeline.
10. New technology: The project depended on a small, private company with a new technology with lots of potential but no track record. Six months into the project, the company was out of business, the software was no longer supported, and there were undocumented bugs everywhere that no one could find.

12 Essential Soft Skills for Project Managers

Generally speaking soft skills are the skills an individual has in relation to their Emotional Intelligence Quotient, their 'EQ'. These cover a breadth of skills including communications, interpersonal skills and how an individual builds and maintains relationships with others. In a project environment getting others to work with you towards a common goal is a foundation stone to delivering a project.

The 12 essential behaviours for project managers are:
* Communication and Consultation
* Conflict and Crisis Management
* Flexibility and Creativity
* Leadership
* Learning and Development
* Negotiation
* Organisational Effectiveness
* Problem Solving and Decision Making
* Professionalism and Ethics
* Trustworthiness
* Self-control
* Teamwork

Communication and Consultation: Interacting with people about ideas, thoughts, facts, emotions, challenges, successes, etc. alongside hard facts such as project progress. Having the ability to convey complex ideas easily; clearly articulate what must be accomplished; keep the team moving toward a common goal; and to foster an environment that allows team members to communicate openly and honestly.

Conflict and Crisis Management: Listening and responding to the needs and views of all team members to anticipate any potential areas of conflict. The ability to diffuse situations where conflict has risen maintains a healthy project environment.

Flexibility and Creativity: Thinking in original and imaginative ways to widen the scope of problem solving when issues arise. Encourage project teams to find the best solution and outcomes without slavishly following generic delivery methods or solutions. Adapting a project's different components, templates, tools, and techniques.

Leadership: Understanding the vision and direction of the project and aligning the team to work towards it. Skills include delegating, coaching, motivating and leading by example.

Learning and Development: Continual improvement of both your own skills and those of your team. Assessment of skills and capabilities, encouraging participation in learning activities and evaluating how the learning is applied in the project environment.

Negotiation: Analysis of information, decision making, establishing the desired outcome and developing a strategy for the negotiation alongside understanding the optimal outcome from several options. Gaining agreement through consensus of positions from both parties.

Organisational Effectiveness: Understanding and applying people management processes and policies. Understanding the corporate culture, the organisational dynamics, and the individuals that work within it lead to getting the best from your team.

Problem Solving and Decision-Making: Resolving issues and solving problems that are a normal part of every project.

Professionalism and ethics: Demonstrated through knowledge, skills and behaviour alongside appropriate conduct and moral principles for both the organisation's and project's environments.

Trustworthiness: Do what you say you're going to do. Build trust with stakeholders involved and convey they can be trusted day-to-day to do what is right at the right time to keep the project successful and the Sponsor satisfied.

Self-control: Self-control and self-management to ensure day to day stresses are addressed and a work / life balance maintained.

Teamwork: Creating a team atmosphere where the team believes that 'we are all in this together' is a critical component to project success.

Source: EzineArticles

Microsoft Project 2010 Desktop

n this latest Microsoft Project release, you’ll find a lot of practical project management tools in addition to some useful bells and whistles to help in your delivery. Microsoft Project 2010 comes with some new features that are a welcome relief to the Microsoft Project learning curve.

1. The Ribbon Navigation

The first and most obvious change is the replacement of menus with the “Fluent User Interface (UI)”, more commonly known as The Ribbon. Since I first used Project in 1996, we’ve had a range of features that were hidden in menus. Now, this interface—already in place for core Office 2007 products—provides more graphical and contextual information by combining the menu and toolbars.

Compare this snapshot of a common Project 2007 menu, with toolbars.

With this view of the Fluent UI, which shows those commands used most often with a larger icon. The UI shows only relevant commands depending on what you’re viewing, such as the Gantt Chart Tools tab that appears at the right because of the active Gantt Chart view.

Compare the Format menu for the Gantt Chart…

with the Format menu for the Network Diagram.

You can even customize the Ribbon so that it contains exactly what you want to see where you want to see it.

Yes, it took me a while to get used to this new interface, and I’m still working to find some of my old friends. Nonetheless, after a brief period of adjustment I am finding that I’m able to use a lot more of the tools more quickly (and, most of my old Keyboard Shortcuts work in the same manner).

2. The Timeline

The Timeline area displays in a simple view the key phases and milestones associated with a Project Schedule. This feature, though simple, is remarkably beneficial for quickly showing everyone the high-level view of the project and its deliverables.

You can easily add to the Timeline by right-clicking a Task or Milestone, and choosing Add To Timeline. In addition, the Timeline shows the time frame shown in the Gantt Chart, as shown below.

3. Manually Scheduled Tasks

When first planning a project, it’s likely that you will have some dates associated with your phases (represented by Summary Tasks), specific tasks, or milestones. Now, rather than Project always assigning a default date and duration to tasks and milestones, you can create Manually Scheduled Tasks.

Observe in the picture below:

•     Task 1 is Automatically Scheduled: the Task Mode property (which now appears as a column in the default Gantt Chart view) is set to Automatically Scheduled. This mode is what you’re used to from previous versions of Project. It is, however, no longer the default mode.
•     Task 2 is Manually Scheduled: the Task Mode property defaults to the Manually Scheduled, which prevents the scheduling engine from acting on the task.
•     Task 3: You can change this Task Mode property using the drop-down field, or by selecting the Manually Scheduled checkbox in the Details (formerly Split Screen) view.

While we may argue about when or whether one should use the Manually Scheduled task mode, or set it to the default mode, I personally feel that it provides a needed tool that Projects Schedulers can use when it is appropriate.

4. Team Planner (Professional Only*)

How can you tell whether your resources are working more hours than they have time available? When will your resources work on tasks? When are they available? In Project 2007 and could to use assignment views, such as Task Usage and Resource Usage. With Project 2010, you can use the newly minted Team Planner.

This excellent view focuses on the resources, and the tasks to which they are assigned.

In this view, you can see that the Programmer is overallocated: we know this because he shows highlighted in red. However, unlike previous versions we can see not only that he is overallocated, but where he is overallocated in the Gantt Chart view. Notice the red lines show the overallocated time.

Now, we have several options for resolving this issue:

•     Use the Leveling tools, which were available in previous versions of project

•     Use the Move Task menu, and choose the When Resources Are Available entry

•     Manually drag and drop the task from the Programmer

•     ….to the Tester (not that we’d want to do that in real life).

This graphical view of resources can help Project Managers visualize the allocation of resources to activities, and more easily work to resolve issues of overallocation.

5. SharePoint Synchronization (Professional Only*)

Project Managers who have the 2010 versions of Windows SharePoint Services (WSS) or Microsoft Office SharePoint Services running will be able to synchronize project schedules with SharePoint-based Task Lists.

In the new Outspace’s Share area, you can connect to the SharePoint site, and then configure the fields you with to synchronize. Most exciting: the synchronization is bi-directional and will allow you to update fields from either the Project client or the Task list on the server; and, you can synchronize custom fields.

Conclusion :

The new features of Microsoft Project 2010 desktop will make developing and managing a project more intuitive for Project Managers new to the tool, and will provide many new tools that will enhance the experience for existing Project Managers.

source: microsoft

IT Project Management illustration

project management illustration by Gary Larson’s Far Side cartoons.

• How the customer explained it
• How the project leader understood it
• How the analyst designed it
• How the programmer wrote it
• How the business consultant described it
• How the project was documented
• What operations installed
• How the customer was billed
• How it was supported
• What the customer really needed

SDLC - Systems Development Life Cycle

The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

Systems development phases:

The System Development Life Cycle framework provides a sequence of activities for system designers and developers to follow. It consists of a set of steps or phases in which each phase of the SDLC uses the results of the previous one.

A Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. A number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize. The oldest of these, and the best known, is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:

• Preliminary analysis: The objective of phase1 is to conduct a preliminary analysis, propose alternative solutions, describe costs and benefits and submit a preliminary plan with recommendations.

Conduct the preliminary analysis: in this step, you need to find out the organization's objectives and the nature and scope of the problem under study. Even if a problem refers only to a small segment of the organization itself then you need find out what the objectives of the organization itself are. Then you need to see how the problem being studied fits in with them.

Propose alternative solutions: in digging into the organization's objectives and specific problem, you may have already is covered some solutions, other possible solutions can some form interviewing may have already discovered some solutions, other possible solutions can some from interviewing people inside the organization, clients or customers affected by it, suppliers and consultants. You can also study what competitors is doing. With this data, you can have three choices. You can leave the system as is, improve it, or develop a new system.

Describe the costs and benefits.
The Document Deliverables during this phase is : Business Requirement Specification (BRS) or Customer Required Specification( CRS) Or User Requirement Specification(URS).

• Systems analysis, requirements definition: Defines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.

Document Input : Business Requirement Document
Document Deliverables : SRS (Software Requirement Specification)

• Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.

Document Input : SRS (Software Requirement Specification)
Document Deliverables : Design Document

• Implementation: The real code is written here (coding-phase)

• Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.

• Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.

• Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This is often the longest of the stages.

In the following example (see picture) these stage of the systems development life cycle are divided in ten steps from definition to creation and modification of IT work products:

Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon the size and complexity of the project, phases may be combined or may overlap.

Strength and Weaknesses of SDLC

Strengths	Weaknesses
Control.	Increased development time.
Monitor large projects.	Increased development cost.
Detailed steps.	Systems must be defined up front.
Evaluate costs and completion targets.	Rigidity.
Documentation.	Hard to estimate costs, project overruns.
Well defined user input.	User input is sometimes limited.
Ease of maintenance.
Development and design standards.
Tolerates changes in MIS staffing.

It is critical for the project manager to establish and monitor control objectives during each SDLC phase while executing projects. To manage and control any SDLC initiative, each project will be required to establish some degree of a Work Breakdown Structure (WBS) to capture and schedule the work necessary to complete the project. The WBS format is mostly left to the project manager to establish in a way that best describes the project work.

Work breakdown structured organization :
The upper section of the work breakdown structure (WBS) should identify the major phases and milestones of the project in a summary fashion. In addition, the upper section should provide an overview of the full scope and timeline of the project and will be part of the initial project description effort leading to project approval. The middle section of the WBS is based on the seven systems development life cycle (SDLC) phases as a guide for WBS task development. The WBS elements should consist of milestones and “tasks” as opposed to “activities” and have a definitive period (usually two weeks or more). Each task must have a measurable output (e.x. document, decision, or analysis). A WBS task may rely on one or more activities (e.g. software engineering, systems engineering) and may require close coordination with other tasks, either internal or external to the project. Any part of the project needing support from contractors should have a statement of work (SOW) written to include the appropriate tasks from the SDLC phases. The development of a SOW does not occur during a specific phase of SDLC but is developed to include the work from the SDLC process that may be conducted by external resources such as contractors and struct.

source: wikipedia and others

A Guide to the Project Management Body of Knowledge

A Guide to the Project Management Body of Knowledge (PMBOK Guide) is a book which presents a set of standard terminology and guidelines for project management. A Guide to the Project Management Body of Knowledge (PMBOK Guide) was first published by the Project Management Institute (PMI) as a white paper in 1987 in an attempt to document and standardize generally accepted project management information and practices.

The Guide recognizes 42 processes that fall into five basic process groups and nine knowledge areas that are typical of almost all projects.

The five process groups are:

•     Initiating
•     Planning
•     Executing
•     Monitoring and Controlling
•     Closing

The nine knowledge areas are:

1.     Project Integration Management
2.     Project Scope Management
3.     Project Time Management
4.     Project Cost Management
5.     Project Quality Management
6.     Project Human Resource Management
7.     Project Communications Management
8.     Project Risk Management
9.     Project Procurement Management

Each of the nine knowledge areas contains the processes that need to be accomplished within its discipline in order to achieve an effective project management program.

Source : www.pmi.org

The Guide recognizes 42 processes that fall into five basic process groups and nine knowledge areas that are typical of almost all projects.

• The five process groups are:

1. Initiating
2. Planning
3. Executing
4. Monitoring and Controlling
5. Closing

• The nine knowledge areas are:

1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project Human Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management

Each of the nine knowledge areas contains the processes that need to be accomplished within its discipline in order to achieve an effective project management program.

The list of Project Management Software : http://en.wikipedia.org/wiki/List_of_project_management_software