Project Management Blog

A good project leader always knows how to make the team work better and with performance. Project leadership provides an opportunity to effective team building and collaboration. Read the top 5 tips in this quick article to find out how to be a fantastic leader of your project.

Take the five tips to improve your leadership skills:

Tip #1. Always Set SMART Goals
If there is no clear direction for your team, there is no way to reach success. The goals of your project will show the team what outcomes to produce throughout the project and what destination to reach at project completion.

You should learn to set SMART goals, which is actually means:
• Specific
• Measurable
• Attainable
• Realistic
• Time framed

As a great project leader, you must keep your goals SMART (specific, measurable, attainable, realistic and time framed). Also avoid setting too many goals. There should be no more than 2-3 goals for a single project. The point here is to create a simple statement of project goals and therefore allow your team to gain a clear understanding of what results to achieve at project completion.

Tip #2. Motivate the Team
Motivation is your essential duty. As great project leader, you must find out exactly what incentives to use to motivate every team member and the entire team as well. Money, personal example, career promotion, recognition are some examples of incentives that you can use to motivate the team and establish teamwork.

Also you should remember about team conflicts and issues. Implementing a combination of team building exercises will help you match everyone’s individual needs, prevent conflicts, and keep the team working as hard as possible towards the project goals.

Tip #3. Keep Track of Project Changes
As your project progressively develops over time, there are some changes that must be monitored and appropriately managed. As a great project leader, you should develop and implement a change responding strategy. Such a strategy determines how to detect, measure the impact of, and respond to a change occurring in the project.

Weekly meetings can be used as a way to manage project changes. Through conducting weekly meetings with the team you are able to review the weekly events and issues, analyze the results achieved or failed, and discuss possible options and solutions. An analysis of the wins and losses through weekly team meetings will help you efficiently respond to project changes.

Tip #4. Reward Top Performers
A great project leader always rewards and recognizes team members for their high performance and contribution. You must know your top performers and constantly think of new ways of rewarding them for the right behavior.

You can try to implement two types of team reward systems, as follows below:
• Target-based reward system, which is to provide a team member with a kind of monetary or non-monetary incentives for the accuracy and timeliness of the targets this individual has hit
• Contribution-based reward system, which is to reward high performers for their overall contribution to team performance and teamwork. The system does not refer to the goals those individual have accomplished, but to the impact they have on the entire team through their top performance.

Tip #5. Exploit Training Opportunities
Time goes by so fast, and your yesterday’s knowledge and expertise may be in lower demand today. If you want to be a great project leader, you must constantly look for ways to improve your team leadership skills and read project manager’s guides.

So keep working on your analytical, communication and presentation skills each week by taking time out to educate on the web, through watching special training videos and taking online courses.

When you exploit training and self-development opportunities, you become more experienced and confident in your project manager role. You will know new ways of treating team conflicts, managing project issues, and establishing teamwork.

It's always a big challenge for a project manager to deal with scoping the work product. I guess reasons for the same we all know as mentioned below.

1. Customers always want more.

2. Architect/ Tech leads thinks every one in the team is as capable as they are.

3. Team always thinks estimation is very aggressive so thats why every one has to stretch their working hours.

4. From organization perspective, organization wants that customer should be always happy.

Here are 10 points that I follow while dealing with such situations.

1. Make estimates considering average capability resource of your team. Estimating keeping high capability resource in mind may lead you to over estimating situation and estimating keeping low capability resource in mind may lead you to under estimating situation.

2. Always include time spent in miscellaneous activities like (work delegation, build promotion to different environments, meetings, communication etc.) in estimation before starting scoping.

3. Before starting scoping request feature priority list from customer so that you could know what will be acceptable to customer if dropped while scoping.

4. While scoping never go by count of features rather go by your estimates. Some time we think that count of features is less than previous releases we have made so we start searching out a way to keep the count same but that does not work practically. you should always stick to estimates rather than feature count.

5. Level the complexity of a release, try to distribute high complex items across iterations/phases of project and make sure that complexity of each iteration/phase is leveled appropriately.

6. Before getting into scope discussion with customer make sure that you have done enough of ground work and you have ready references available for all high valued items estimates as most of the time discussion will be focused on high valued items only.

7. Never estimate for shadow staff given to your team. It does not mean that you will not give work to shadows, they should be used to share load of main resources.

8. Review the scope twice before sending it to customer because you should be convinced fully before customer or any one else accepts it.

9. Keep eye on productivity figure of previous releases you made this should fairly give you idea what can be covered and what can not be.

10. Never plan to deviate from processes to cover extra scope. This will lead you to serious quality issues.

There are off-course more additions you can make to list but for now i think above are quite helpful while doing scope negotiations.

Read it on the blog is a project and engineering management discussion blog. A kind of 'Carrie Bradshaw' view of the engineering blogging world, only without the shoe fetish!

The aim of this, my second blog, is to open a debate on what is the most appropriate organisational design for companies that are required to deliver high value operational work alongside high value investment programmes. The blog assumes a basic understanding of functional, projectized and matrix organisations. For readers who wish to understand more about these definitions an excellent overview can be found at wikipedia.

I welcome reader engagement and feedback of your views and personal experiences regarding how organisations structure themselves to deliver the different capabilities of ongoing operations and project delivery. If you wish to comment please click the title of this blog and enter your comments in the box at the foot of the page.

Some options that I have encountered include:

1. Create separate functions for operational work and programme/project delivery, alongside typical support functions such as Finance, HR, Legal, IT etc.

2. Create a single function that delivers both operational work and programme/project delivery, alongside typical support functions.

3. Establish separate business divisions for operational work and programme/project delivery, each division containing all the necessary resources required to deliver its objectives.

4. Establish a matrix organisation, containing functions that are tightly defined centres of excellence alongside a programme/project delivery function that is accountable for defining the 'what' (programme scope), 'when' (programme schedule) and 'how much' (financial plan) by jointly managing resources within the the other functions whose leaders are primarily accountable for the 'how well' (quality).

So now for the 'Carrie Bradshaw' bit

Option 1 may be ideal, providing the demand for operational work, is closely matched to the direct labour resource capacity such that the organisation can meet its required levels of service whilst achieving high levels of resource utilisation. In other words there are no stranded resources or 'fire departments'. But how often does this situation apply in reality? Possibly in the case of organisations that manage continuous processes, but not so for utilities whose assets are exposed to the effects of weather and other external factors.

Option 2, in my experience, is adopted to address the issue raised in option 1 such that, by combining operations and investment delivery, an opportunity for utilising operational resources on project work during periods of low operational activity is provided. But what does this mean for project delivery ? What happens to projects when the organisation experiences high levels of operational activity? How can programme/project managers produce accurate programme schedules when they don't know what resources they have at their disposal ? Does programme/project delivery become the poor relation to operational work?

Option 3, is ideal for organisations whose operational activities and investment delivery activities are dissimilar such as water and waste water utilities and where the demand for work is extremely large. Each division being essentially a standalone organisation.

Could option 4 be a solution to the issues experienced by option 2? Establishing a professional programme & project management department within the investment delivery function. A function whose accountability is to deliver the organisation's investment programmes utilising a common programme management methodology based on best practice and the needs of the organisation. Could this be achieved whilst maintaining a close relationship with the other functions in the organisation through joint management of resources? Is it possible to be 'best' at operational work AND project delivery, or does one always succeed at the expense of the other?

I welcome all views, especially those relating to utility industries, please comment.

Written by Chris Pinter

February 1, 2010

The development of new technology starts from a marketing perspective. It is important to know what you are building before you build it. Business Analysts’ are constantly asking the question… What does the market want? Knowing the answer is the key to success. Documenting the facts and key features is the essence of the requirements document. It is best written by business analysts and marketing professionals.

The requirements document is the first document that is used to build a technology. According to Wikipedia.com the Product Requirements document (PRD) is designed to allow people within a company to understand what a product should do and how it should work. [1] This document directs the development team in what the needs are and is used to create the technical specifications.

A good requirements document has the following areas addressed:

1. Purpose and scope

The purpose and scope of the project should be well defined. The best way to do this is to use the S.M.A.R.T. approach to setting goals. The purpose and scope must be Specific, Measureable, Attainable, Realistic and Timely. [2]

2. Identify stakeholders

Identify everyone who has an interest in the project. This list of interested parties will consist of members who want a positive outcome and members who do not. Some examples include the client, customer, executives, lobby groups, strategic partners, government organizations, project managers, and members of the development team.

3. Market assessment

The market assessment section should include as much information on the market as required to outline the project. It should include a brief description of the problem, specifically why this project is necessary and the target audience, who has the problem. It must also include the market size and potential market acceptance so that the development team knows the likely volume to design to. Products that have a potential of 5 million pieces per year require different design criteria than those products that have a potential of one thousand units per year. The competitors and similar products on the market should also be noted so that there is a reference to the technology of the day.

4. Product overview and use cases

The product overview is the vision of how the product solves the market problem. This can be described using a series of use cases. Each example describes how the product will be used in each situation thereby solving the problem in different ways or solving a group of similar problems with a single solution.

5. Product requirements

The product requirements section describes how each aspect, notable condition, feature or function the product must possess. The requirements can include function, usability, environmental, interacting and interfacing requirements. It is important that each requirement be well defined in specific measureable terms. A measure of minimum and maximum should be used wherever possible.

6. Supporting business requirements

Development projects are very seldom developed in isolation. Many other business departments and organizational resources will be used to promote, service and maintain the new technology project. It is important to recognize the need for these departments as there are costs and procedures that will need to be recognized and developed.

7. Known risks and constraints

In order to achieve a competitive advantage in the market place, risks must be overcome that your competitors cannot. It is important to recognize the technical, procedural and business risks and constraints that may affect the project.

8. Workflow constraints

It is not required to outline the schedule, budget, and tasks required to complete the project in the requirements document. However, it is important to recognize any time, environmental, budget or resource constraints that must be considered when planning the project.

9. Evaluation plan and performance metrics

How the project is evaluated for quality and the performance completes the requirements as these measurable aspects of the document will affect the feasibility, budget and schedule of the project.

The requirements document outlines the customer needs and the factors that will affect success. The primary use of this document is to direct the development team in creating a technical brief and project plan. The schedule, budget and deliverables can then be outlined and decisions can be made on the return on investment (ROI) for the project. So… provide as much information as possible.

I'm a momma's boy. I call my Mom every week just to hear her voice, get her views on important decisions, and ask her for $20 for gas. We don't talk long. We have mutual hang-up pact after five minutes. Click we're done. Those five minutes are important to me.

My Dad was the undisputed head of the household, but Mom quietly ran the whole show behind the scenes. She taught me to tie my shoes, balance a checkbook, play baseball, fold shirts. Who forced me to sit at the table every night and do my homework? Mom. Who once pinned all six of my brothers, sister and me at one time in a wrestling death match? Mom.

Leader's don't complain
Mom has all the answers to the thorny problems in life. For example, I once called her for advice on raising my daughter. In truth, I wasn't looking for advice. I just wanted to complain about how hard it is to raise a kid nowadays. She quickly set me straight, "Tell it to someone who doesn't know better. Do you really think that you and your brothers were angels? Your Dad used to say that raising you kids was ‘like raising a litter of six Dobermans - all rabid."

Why do we feel that complaining somehow makes a situation feel better? It feels like everybody is walking around with the need to vent. Take your situation at this moment, for example. Right now, you've got pressure from the job and from the home front. Something is causing you pain or anxiety. You complain about that issue to anyone who will listen. We're all behaving like nobody's seen the troubles we've seen.

Call my Mom and she'll set you straight. The conversation will likely end with "Stop complaining and do something about it or toughen up you big baby." She's earned the right to dispense this tough love counsel because I never heard her say that her problems were unique. I never heard her grumble about how hard it was to raise six rowdy kids. When I was expelled from High School, she responded: "You're going to work with your dad [a mechanic] on boat engines in the Florida heat from 7:00 am to 9:00 pm while you enjoy your time off school." Dad got free labor. I learned the value of staying in school.

Leaders don't complain. They just roll with the punches.

In today’s complex company environment new projects are continuously being developed as organizations seek new ways to lessen expenses, enhance processes, increase productivity, and build their bottom line. Managing these diverse projects along with their individuals, resources, technology, and communication is really a challenging endeavor for which the risk of failure is frequently far too high. An powerful solution, created to establish a a lot more centralized management structure for large groups of projects, will be the Project Management Office (PMO). The PMO gives organizations with an infrastructure of folks, procedures, and tools to obtain powerful project management by leveraging project management standards, allocating resources, establishing consistent performance measures, and reducing duplication of efforts.

There are several benefits to establishing an effective PMO. 1st, the PMO supplies a framework for consistently managing projects through a regular methodology while ensuring the projects are aligned with corporate objectives and techniques. Project managers have clear lines of responsibility whilst coordinating folks, processes, and tools with one yet another and by doing so, steer clear of both gaps and overlaps between projects and decrease or eradicate duplication of effort. Standardization and repeatability afford an organization better communication, reduced project price, improved resource management, a lot more accountability, improved top quality, greater forecasting, and less overhead related to project managers.

Enlist Executive and Management Support
The first step in establishing a PMO is gaining executive and management support. This step relies heavily on organizational change management (OCM) as it demands a potentially considerable shift in organizational culture together with roles and responsibilities. Regardless of the difficulties and resistance to alter, this step is the foundation upon which a profitable PMO ought to be built. As with any shift in organizational structure, policy, or procedure, favor ought to be gained via justification for the modifications in terms of cost benefit and return on investment (ROI).

Decide the Structure and Develop the Team
The next step in constructing a PMO would be to decide the structure and develop the team. There’s no defined template for PMO structure as every single organization brings its own variables to consider. Some manage all aspects of the projects assigned under them like scheduling, budgets, resourcing, human capital, oversight, and communication. Other people might strictly coordinate these functions with most of the support coming from adjacent departments. The keys to determining the right structure and team members for the PMO are understanding one of the most powerful way they can co-exist within the organization and discovering the proper balance between the PMO, organizational culture, roles and responsibilities, and management style. Some issues to think about in establishing the structure and developing the PMO team include: availability of resources; existing project management standards and methodologies; existing roles and responsibilities; the politics of the organization; project size and volume; and present project management troubles.

Develop and Document Standards
When the structure and team members have been determined, it is time to develop and document the PMO standards, practices, and methodologies for project management. These standards will enable for consistency across the organization and its portfolio of projects. They’ll also comprise a huge portion of the training that projects managers and staff will obtain in the next step. Standardization is also an essential part of allowing an organization to compare a variety of projects and allocate resources where and when they’re essential.

Identify Abilities and Train the Staff
Once the development of project management standards and methodologies is complete, the PMO need to identify the proficiency levels and skill sets of it project managers and staff as a way to determine what training is essential. Some of this information will likely be evident as a result of reviewing the statuses of current projects. Significantly of the training content may also be based on the standards, practices, and methodologies that had been defined in step #3. The PMO really should also establish an ongoing training program. In a PMO it really is inevitable that staff members will come and go and organizational standards will alter and evolve. A training program will make certain that all new employees receive training on those standards and existing employees remain conscious of any modifications.

Measure Success and Continuously Improve
Now that the PMO structure is finalized, project management standards are established and communicated, and personnel are trained, the focus of the PMO need to shift to assessing and measuring success. This point in time marks the initiation of progress and performance reporting based on standardized tools, templates, and methodologies. Even so, it also marks the beginning of a continuous method improvement cycle along with a transition from PMO deployment to operational sustainment. As the PMO evolves, project team members should maintain an awareness of the metrics by which their projects are measured along with how method effectiveness is determined. There must be a concerted effort to identify processes which need improvement. When identified, improvement measures need to be developed and implemented.

The establishment of an powerful PMO is beneficial to any organization which manages a portfolio of projects. When planning and developing a PMO it’s imperative that it is accomplished in a manner which compliments the existing structure or the organization. This will enable the company to gain maximum benefit and to do otherwise could be counter-productive. Since every single organization is different, the optimal structure for the PMO need to be developed based on numerous considerations and variables. The capability of a PMO to manage projects by way of consistent and repeatable standards and methodologies brings numerous positive aspects. It supplies the organization with accountability, continuity, simplified oversight, along with the capacity to measure project success a lot more successfully. An efficient PMO can be a catalyst for higher efficiency as it makes it possible for an organization to do far more quality work with fewer resources and much less risk. The result of these positive aspects is an organization that may significantly boost its project success rate.

Original Site: http://www.mypmhome.com/how-to-build-a-project-management-office/

In my previous blog, posted here on the 28th of February, I spoke about the first key to Successful Improvement Projects; “An Uncompromising Focus on the Customer.” At the conclusion of that posting, I promised to follow it up with the second key; Senior Sponsor Support. Read on to find out about the second key…

It is a waste of time to go about improving operations or implementing a new project unless there is a senior sponsor that will advocate, exert influence and resource the project. If the sponsor is not passionate about the change - do not start! I have seen numerous ingenious innovations left to die on the vine. Why? Because the leader was focused on important, urgent and immediate issues while creative people in the organisation had great ideas but no mechanism to bring that idea to market. The senior sponsor plays a critical role when bringing about changes to the business. Sponsor support happens at two very different levels. You need the sponsor’s ‘head’ to provide you support with resources and people. More importantly you need to tap into the sponsors ‘heart’, to find support in the form of an excitement and passion for the improvement. I discuss this further in my newsletter, Silver Bullet 7. Visit Silver Bullet.pdf for more information.

This newsletter includes some practical tips on engaging your sponsor.

As the project rolls out, ensure you maintain communication with the sponsor to give feedback, receive direction and maintain a level of excitement about the success the improvement will bring.

In my next post, I will explore the third key to Successful Improvement Projects: A crystal clear vision.

Dan Jackson
Head Coach 7SIM Business Improvement
www.7sim.com.au

Whenever scheduling a project , check for the following

1) Padding of task durations
Team member will play it safe by buffering time required for tasks. This approach usually results in various time wasting practices, e.g., waiting until the last moment to complete a task. As a result, all the safety time can be wasted at the start of the task so that, if problems are encountered, the task over-runs.

2) Multi tasking
When the team has been assembled from various divisions, they don’t expect to stay busy with just this one task – so they plan working on several tasks at once by switching between them. The result is that everything takes a long time to complete and very little completes early.

To ensure effective plan,

Get the project sponsor to announce the go live date.

Get the team to schedule backwards from the go live date w/o built in buffer.As a rule, the team should reduce activity duration estimates significantly compared to the typical approach.

Plan for an overall project buffer and insert this at the end of the project.

Ensure critical resource unavailability by escalation and enough hell raising.

Focus on the core activities and leave standalone activities to the last.