Project Development Plan - The First Guide in Building an IT System

When my team had an IT project to do during our college days, we used a very important document to help us get started during the initial stages of the project. We used a document called Project Development Plan (PDP) as guide. It is adapted from the IEEE standards for Software Project Management Plans. This document is very useful because all succeeding documents (i.e. Test Plan) follow the initial guidelines stated in the PDP document and the general details and strategies for testing and quality assurance are also stated in this document.

Apart from minor (but pertinent) details, the PDP is divided into four major parts, namely: Project Organization, Managerial Process Plans, Technical Process Plans, and Supporting Process Plans. The Project Organization part of the PDP document describes and illustrates the organizational hierarchy of the developing team. The Managerial Process Plan section of the PDP describes how the developing should start and how it will close. Apart from which, this section also tackles the general and specific details of managing resources, budget, staff and schedule. The Technical Process Plan part of the PDP is where the process, methods, tools and techniques in building the system, as well as maintenance and release, are stated. And, the Supporting Process Plan section of the PDP provides general details about configuration management, testing, standards and quality assurance, reviews, issue management, subcontract management and improvement plan. This part is essential because many documents particularly the Test Plan and the Quality Assurance documents base its initial plans, standards and processes.

The first part of the Project Development Plan document details the purpose, scope and objectives of the project. Of course, the developers of the system must know what they are building, and the limitations and extent of the finished product. The initial section of the PDP also enumerates the list of deliverables of the project like documents and the finished system itself.

The first major part of the PDP document is the Project Organization. This is where the internal and external organizations are identified, together with their roles and responsibilities. Improper or poorly defined position in the organization causes confusion amongst the members of the developing team regarding each one's roles and responsibilities; causes some members of the team to slacken around and do nothing, while some have more than enough in their hands; and some members tend to assume the responsibility supposed to be assigned to another team member. Thus, poor staffing or poor Human Resources management might contribute heavily to the project's total failure.

The second major part of the PDP document is the Managerial Process Plans. This is where the specific and general management process for the project appears. While doing this part of the PDP before, I find the contents of this section repetitive especially in the areas of schedule, budget, staffing and resources management. There are certain developers who don't have to worry about estimating schedule, budget, staffing and resources because the company where they are employed provides them with all the things that they need. However, there are developers who must do all the estimating and budgeting. Thus, the Start-up Plan (under the Managerial Process Plans) is where all the initial plans of the developers are found. Usually, this plan came about during the pre-Requirements stage. The opposite of the Start-up plan is the Close-out Plan that discusses how the project should end. Work Plan section (under the Managerial Process Plans) is where the specific details of budget, schedule, staffing and resources are found. Also, we can have an early glimpse of the Work Breakdown Structure and the specific work activities. Risk Management Plan (under the Managerial Process Plans) describes the mechanisms used to identify, analyze, build mitigation and contingency plans; and manages the risks possibly found in the project.

The Technical Process Plans describe the processes used for developing the product or IT services. The activities in the Work Breakdown Structure follow a guideline in the form of a Software Development Life Cycle Model (i.e. Waterfall Method). If a Life Cycle Model is not determined, sometimes it is difficult to prioritize the activities in the project.

Lastly, the Supporting Process Plans of the PDP discusses the supporting processes of the project, namely: configuration management, testing, documentation, quality assurance, reviews, issue management (which I find somewhat similar with Risk Management), subcontract management and improvement plan. Configuration management has something to do with the configuration items identified in the project. These configuration items are already named as early as pre-Requirements stage but they are visible for every phase-end or if an item is already declared original and final version. Samples of configuration items are documents. Once changes are made in these items (which normally happens during project-end), a control board analyzes changes prior to acceptance or rejection. The analysis of the control board is one of several activities under Configuration Management. The general guidelines for the Test Plan and the Quality Assurance Plan documents are first planned and described in the Supporting Process Plans of the PDP. Without the initial guidelines, there is a huge possibility that testing and quality assurance activities are taken for granted.

The Project Development Plan document is very important and essential especially if you're into software development. Without this document as guide, an IT developer might experience "groping in the dark" in the middle of the project, NO FORMAL GUIDELINES AND STANDARDS established, and there is poor management in areas of budget, staffing, schedule and resources.

P. Lobrin
plobrin@gmail.com

Dedicated to IT Project management and Software development.

Article Source: http://EzineArticles.com/?expert=Paulita_Lobrin

Best Practice Guide To Project Success

1. Question The Need For The Project

The quickest, cheapest and simplest way of improving your organisation's levels of project success is to stop starting new projects. Question whether your new project is really required right now. If you aren't going to do anything different between this new project and a previous project, chances are that this one will fail as well.

Instead plan a strategy for improving your project success rates. Once you have begun to implement some of the changes the start new projects. For the time being, stop projects failing by simply not starting any new ones.

2. Always Prototype Solutions

The use of prototypes will improve the rates of project success. From simple pictures and diagrams to functional working models, prototypes will improve the frequency, quality and quantity of stakeholder feedback into a project.

Train project members to storyboard user scenarios. Look to include a web developer in the plan to create basic mock-up application screens. One of the first deliverables in any project plan should be a form of prototype. Start getting stakeholder feedback as soon as possible.

The most effective teams, build prototypes, get feedback and then incorporate the feedback into the next set of prototypes. By providing stakeholders with this level of attention and focus leads to greater support. Individuals like to see their vision and ideas presented as a tangible entity rather than as a set of bullet points in a document.

3. Don't Always Use Standard Templates For Documentation

Project documentation rarely gets properly read and fed back on. Stakeholders are too busy to read the amount of information that they are expected to read through and comment on. Invariable most will simply skim through large documents, read the executive summary and provide some high level feedback. The risk of this is that the Project Manager and team believe that they have got stakeholder buy-in whilst in reality they have just been lucky (unlucky?) because an area of potential contention has been missed by a stakeholder. Let the team document what is required against a set of prompts not rigid templates.

4. Make Sure Everyone Is Together

Where feasible make sure all of the project team are located in the same office. The quality and ease of communication flows directly affects the levels of project success.

Teams located in close proximity with their suppliers and other project members benefit because:

* Face to face communication is proven to be the most effective form

* It reduces the time of feedback loops

* It builds stronger team relationships

5. Give Them Space

If you want a successful project then you need team members 100% focused on delivering. Put the somewhere where they can't be distracted from usual e-mails and telephone calls. Ideally rent project space away from your offices. This prevents any distractions as well as encourages teams to focus on the task in hand.

Whilst stakeholders will have to travel to the project team it will ensure that once there they will devote their time to the project team's needs.

6. Team Building

As the project sponsor make sure that you have an effective team working for you. Are they motivated to deliver the project? Do you know the team dynamics? Be prepared to change team members if the dynamics aren't working. Also invest in team-building activities early in the project and on an ongoing basis.

7. Fail Quickly

Tom Peters advocates the merits of failing fast. Don't drag out a project's failure/ Instead fail with gusto and support the project team. Because you've failed quickly you still have time to make amends with a new project. This time you have learnt about the issues and problems that you will face. This greatly improves the chances of the project being a real success this time.

8. Measure Real Progress

As a project sponsor you shouldn't be asking for weekly activity updates, risk updates and traffic-light reports. Your main priority is to ensure that the project team are producing real tangible value. Put in place value milestones (E.g. first product sold, first real customer feedback). Direct the team to focus on business value above and beyond anything else. Measure progress against these value milestones not just activities.

9. Don't Audit Your Projects By Default

Project Audits cause project team large amounts of work. None of this work creates any value and is an unnecessary process for the project. Trust your team that they are managing the project budget and risks adequately. If you have concerns then ask the team (not just the project manager) questions until your concerns go away.

10. Brand The Project

Projects should have their own identity and brand that is recognisable across the organisation. Encourage team members to be creative with project names and branding. Choose names and colours that generate interest and a positive buzz.

11. Interview And Advertise For Project Members

Being selected for a project shoould be seen as a privelege and exciting opportunity. You need to nurture a clulture where the best staff are selected for project work. A simple yet effective way of achieving this is by ensuring that all project member are interviewed for project roles. Advertise up and coming projects internally on your intranet and notice boards. Make projects cool and exciting by rewarding successful projects with perks and bonuses. make it that your best people want to be on the most challenging projects.

12. Only Worry About Real Risks

Risk management within the project should focus on the direct risks only. Risk registers can be over populated with large risks that if they occur will have a far greater impact than on just the project. Take ownership of the large company risks yourself as the project sponsor. Get the team to focus only on risks that are local and could impact the project.

13. Let Teams Work To Their Own Heartbeat

Each project team is unique, don't impose your individual way of working on the team. Encourage them to work in the way which delivers the best results. Casual clothes, late starts, early finishes; none of these matter on a project if the project is delivering exceptional results. Focus on the results and let the team work the way they want to.

14. Get Experts In When You Need Them

At specific points on a project it is wise to get in experts to help. If your team is weak in requirements gathering hire specialist requiremenst analysts. If you need help putting together business cases and project plans then recognise this and get external help.

When selecting consultants their experience and portfolio of work is important. But it is more essential that you and the project team can work with them on a personal level. Look for clear jargon free communication and individual personalities that will fit in with your company culture.

15. Sell The Project

Organisations normally have numerous projects under way at once.If you want your project to be a success then you are going to have to sell its benefits. You will need to sell to ensure that you get access to the best resources. You will need to sell to raise the profile of the project so that the team are motivated to deliver. Talk up the project team with other senior stakeholders and encourage them to get involved. Get their support by selling the benefits and the project will have more chance of succeeding.

16. Benchmark And Strive Higher

Don't aim for mediocre results. Benchmark the best solutions available in your industry and beyond. Measure your deliverables against the best in class and aim to become the best. Don't accept budget or resource limitations. Some of the greatest inventions and products were delivered on shoe-string budgets. Sell your project vision with passion and the project team will aim for it. Believe in the project team and they will deliver exceptional results.

17. Mix The Team Dynamic

Successful teams require a healthy mixture of skills, personalities and experience. Consider the different individual personalities when putting the project team together. Put together different ages and perspectives.

18. Refresh The Team

Adding fresh resources into projects that become stale is a good way of revitalising the project's energy levels. New ideas and perspectives can help to break any deadlocks.

19. Incentivise Suppliers

If your project is dependent on external suppliers then provide incentives to ensure they will be rewarded on good performance. Encourage them to deliver early through project bonuses and reward schemes. You want your suppliers to be dedicated to the success of your project and incentivising them financially will guarantee their focus.

20. Encourage Teams To Document Only When It Hurts

An approach borrowed from the 'Agil Alliance', project teams should be focused on delivering value and not necessarily documentation. Unless the documentation is a critical part of the required outputs then teams should be looking to capture information in a temporary format. Make sure teams have lots of whiteboard space and flip-charts. This will save the team time and energy and allow them to focus on the real value, the deliverables.

21. Ask Questions And Stay Involved

Keep involved with the project. Ask open questions and closed ones. Keep the Project Managers on their toes. Be there to support them nut make sure that they know that the project is important to you. Stay involved with the project and anything you can to help them.

22. Do Something

Projects continue to fail because teams continue to make the same mistakes. Take charge of the situation and don't accept poor projects. If the project is going to fail then make it fail fast. Learn from the failure and start another project with greater chances of success. Stay positive and believe that with the right tools and support your projects can make a difference.

Share This Article With Other Senior Managers And Discuss How You Will Improve Your project Success Rates

Lee McCance is an experienced Project Manager and Business Analyst. Specialising in delivering technology projects and with a track record of rescuing failing projects. A PRINCE2 practitioner he also has delivered projects using agile and lean methodologies. He is able to communicate effectively between technical teams and senior management.

For more project management and business best-practice resources visit http://www.protoolkits.com

Article Source: http://EzineArticles.com/?expert=Lee_McCance

Project Management Guide - Identifying Risk

Identifying risks can be a tricky business. But there are a few things you can do to make it more successful. The first thing we need to do is look at what we are actually trying to find. We are trying to figure out what things could happen that will effect the project in a bad way.

So what would be a bad effect on the project? Well, traditionally we are trying to protect three main areas in a project: time - how long it takes us to complete the project; cost - how much it costs us, in terms of money and resources; and scope - what the final output will actually do. In addition, the quality of the final output can be effected.

By keeping these four areas in mind, we can start to identify what some of the risks could be.

1. What could happen that will affect how much time we have?
* Could the launch date be moved forward?
* Could poor weather conditions delay external work?
2. What could happen that will affect how much money we have, or can spend?
* Could the project budget be cut in a lean time?
* Could our suppliers put their prices up significantly?
3. What could happen that will affect the scope of the project?
* Could a competitor put out a product which covers something we don't, meaning we need to expand scope?
* Could part of the project be more complicated than expected?
4. What could happen that will affect the quality of the output?
* Could a component from a supplier not meet our requirements?
* Could we run out of time for removing bugs from code?

By identifying the things that could happen that will affect us, we can not only identify them as risks, but also identify the drivers behind them - what will cause these risks to occur? In that way, we can start to make sure we head the risks off early, and hopefully make sure they don't occur.

Trevor Roberts is a project manager who runs his own project management consultancy, working with business and government to help deliver successful projects. He is passionate about project management and its importance in helping organisations achieve success. He is continually learning more, and passing on what he has already learned to others through his blog http://www.ProjectManagementGuide.org where he aims to help you learn more about project management. You can follow Trevor on Twitter at http://twitter.com/trev_roberts

Article Source: http://EzineArticles.com/?expert=Trevor_Roberts

Project Management Concepts - Most Important Resource

I've been giving some thought recently as to what lies behind the work we do as project managers. Too often we get caught up in the tools and techniques, the how of what we do, without looking at the concepts and ideas behind it, the why of what we do.

Today, I want to look at what is controlled, the resources that we can use to carry out the work of the project, and particularly the most important resource. The concept I am looking at today is: The project team is a project's most important resource. Guard them well, to allow them to get on with their tasks.

We already know that we can, within limits, control time taken, money spent, and scope fulfilled. But how are they controlled? Essentially, we are looking at how we can control these three resources. A project manager will have a certain amount of time and money to achieve a certain amount of scope.

But the key resource, the one which effects all of the project, is, of course, the team of people who are actually doing the work. In them, the three areas of control are combined.

Each of the team members has only a limited amount of time they can work on the project. Each of the team members will need to be paid for. And each of the team members will have different skills, and different abilities. Project management, then, needs to be able to guide the work of the team in the right way. We must allocate the work to the right individuals, giving guidance as to how long to spend on it, what quality is needed, and, if expenditure other than that on the team member's salary is needed, how much can be spent.

So, we need control of the resources allocated to the project, and that includes the team. But, unlike money and time, team members can easily be distracted and pulled off to work on something else. But a project manager needs to retain control.

This leads us to a project management concept: The project team is a project's most important resource. Guard them well, to allow them to get on with their tasks.

Trevor Roberts is a project manager who runs his own project management consultancy, working with business and government to help deliver successful projects. He is passionate about project management and its importance in helping organizations achieve success. He is continually learning more, and passing on what he has already learned to others through his blog http://www.ProjectManagementGuide.org where he aims to help you learn more about project management. You can follow Trevor on Twitter at http://twitter.com/trev_roberts

Article Source: http://EzineArticles.com/?expert=Trevor_Roberts

Performance Management - Before Implementing a System

Performance management is about controlling the performance of the organization. Most of the time this starts by the financial figures that are set as a guide for the company. We target a certain return on investment, an efficiency ratio or a profit per share ratio. These ratios provide a guide for management because they represent real targets.

The challenge is to link these financial figures to personal objectives, or personal performance criteria. Compare this with a project planning. The (overall) company ratios could be seen as the deadline of the project that you set at a certain point in time, but you still have no idea whether your human resources are able to finish this project, nor what would be a reasonable (resource) benchmark for this project to finish.

But the law of the market defines that we first set our target and then we assess whether we will make it. Pressure is a good friend in business but incredible deadlines will de-motivate.

The productivity matrix will help you in this area, because productivity is measurable at any level and takes into account the direct and indirect contribution to the output. But also in this case you should only implement such a heavy (performance) measurement system if you are going to finish it. The comparison with project management is again very useful; you should (only) implement project management when the risk of missing such a mechanism is bigger than the overhead (costs) that you add to your business.

A step towards a formal performance management system is to address those issues that are key for your business. And these are normally also the issues that are not easily to set performance indicators for. Image that your football team is losing. The performance target is not met. But then, what could have been improved; the defense, the attack or somewhere in the middle, connecting both ...? If you know this, you know how to improve your performance.

© 2006 Hans Bool

Hans Bool is the founder of Astor White a traditional management consulting company that offers online management advice. Astor Online solves issues in hours what normally would take days. You can apply for a free demo account

Article Source: http://EzineArticles.com/?expert=Hans_Bool

Project Management - Project Life Cycle

Project Life Cycle has four phases:

* Initiation
* Planning
* Execution; and
* Closure

Project Initiation

The Project Initiation is the 1st phase in the Project Management Life Cycle.

The most common tools or methodologies used in the initiation stage are Project Review, Plan, Overview and Schedule Reviews.

You can start a new by defining its objectives, scope, purpose and list of deliverable to be produced. Professionals and skilled project team also being selected in this stage by the appointed Manager.

Project Planning

The Project Planning is the 2nd part in the Project Management Life Cycle. The 2nd phase should include a detailed identification and assignment of each task until the end of the assignment. It should also include a Risk Analysis and a definition of criteria for the successful completion of each deliverable according to the Schedule prepared by the Planning Engineer.

It involves creating of a set of plans to help guide your team through the execution and closure of the business assignment.

The plans created during this section will help you to manage time, cost, quality, change orders/variation, risk factors and other issues. They will also help you to manage key personal and external vendors/suppliers, to ensure that you deliver the project on time and within schedule.

Project Execution

The Project Execution is the 3rd phase in the Project Management Life Cycle. The Project Execution is usually the longest phase in the project life cycle and it typically consumes the most energy and the most resources. You will build the physical deliverable and present them to your client for approval.

The most important issue in this part is to ensure activities are properly executed and controlled. You will need to implement a range of management processes during this section. These processes help you to manage time, cost, quality, change orders/variation, risks factors and issues. They also help you to manage procurement, client approvals and communications.

The most common tools or methodologies used in the execution phase are an update of Risk Analysis Review, in addition to Project/Business Plan. The planned solution is implemented/incorporated to solve the problem specified in the business requirements.

Project Closure

The Project Closure is the 4th and last phase in the Project Management Life Cycle. In this last stage, the Project Manager must ensure that the Business Assignment is brought to its proper completion (according to contract).

The closure section is characterized by a written formal project review report contains of overall level of success to your sponsor in the phase. Project Closure involves handing over the deliverable to your client/customer, passing the documentation to the client/business development, demobilizing/releasing staff and equipment, and informing stakeholders of the closure of the business assignment.

Between one and three months after the project has been closed and the business has begun to experience the benefits provided by the project, you also need to complete a Post Implementation Review.

This review allows the business to identify the level of success of the project and list any lessons learned for future projects.

"Nobody plan to fail, but they fail to plan"...

If you are interested in reading more on Shekar's Articles visit PROJECT MANAGEMENT check this website to learn more and share on Project Management.

Article Source: http://EzineArticles.com/?expert=Shekar_Pm

Project Management Institute

The Project Management Institute (PMI) publishes standards related to project management and manages certification. Its headquarters are in Newtown Square, outside Philadelphia, Pennsylvania.

Overview
PMI, founded by five volunteers and incorporated in 1969, has published a number of standards related to PM skills, and manages several levels of certification. A Guide to the Project Management Body of Knowledge is currently in its third edition, and is the only ANSI standard for managers. The levels of certification are (CAPM), (PMP), (PgMP) and the latter being more advanced.

Membership
As of 2006, PMI reported over 220,010 members and over 180,000 PMP certificants in 175 countries. There are more than 250 local PMI chapters located in 67 countries, and 30 Specific Interest Groups (SIGs).

Certification
Over 44,000 PMP certifications expire annually; a PMP must document ongoing experience and education every three years to keep their certification current. This experience and education is measured in Professional Development Units (or PDU's) and can be earned from a variety of sources (such as taking or teaching classes focused on the PM discipline).

Not For Profit Status
The PMI is self-described as a "not-for-profit" organization. It has been widely questioned if it was established and is currently maintained for the betterment of the PM discipline or for profit. PMI attaches fees to various activities related to acquiring and maintaining the PMP certification (e.g. membership fees, certification fees, materials revenue, class fees, etc.) however there does not seem to be any corresponding monetary outlays related to same. As hinted at above, even the instructors for various classes are volunteers who are paid in the form of PDU's. This free labor allow the PMI to enjoy significant and continuing streams of income with minimal expenses.

Operational Goals
It has been argued that if the organization does exist for the betterment of the PM discipline, it would make its materials (namely, the PMBOK) available free of charge. Instead, it is copyrighted and fees are charged to obtain it (whether directly or indirectly through joining as a paying member of the PMI).

To generate even more demand for the certification, the PMI is pushing an initiative to the professional sector: all project managers should be PMP certified. As firms adopt this 'ideal', they are pushing current and prospective employees to get the accreditation.

http://basedprojectmanagement.blogspot.com/

Article Source: http://EzineArticles.com/?expert=Kevin_Vida