Shoeboxed.com | Your Documents Online
Have you heard of Shoeboxed.com yet? It’s a web service that scans, data enters, and organizes your receipts, bills, and business cards online. I thought you might be interested in trying it out, so click here for a 30-day no risk trial.

Best,

Ruben Raposo

Connect with Shoeboxed on Facebook Connect with Shoeboxed on Twitter
Connect With Shoeboxed
Click here to unsubscribe from invitations from Shoeboxed users. © 2012 Shoeboxed

seg?add=179822

Advertisements

10 December, 2010 22:55

December 10, 2010

http://qawofika.110mb.com/rynyruce.html
Collab orat eWithYo urT alentO nline

Team Building

November 11, 2010

Team Building

In the competitive world we live in; with all of our individual goals; it is difficult to assemble a “team” of individuals that will effectively reach a certain business goal or objective. It is no secret that the majority of projects fail. If this is so, how do we increase team performance? Businesses, schools, sports teams, religious or nonprofit organizations use the technique of team building to improve team performance.1

What is team building?

Wikipedia refers to team building as a wide range of activities designed for improving team performance. Teambuilding is an important factor in any environment; its focus is to specialize in bringing out the best in a team to ensure self-development, positive communication, leadership skills and the ability to work closely together as a team to problem solve.1

Now, what exactly do you mean by team?

A team is not to be confused with a group. It is easy to consider these synonymous, but a group consists of number of individuals in which each person performs specific tasks given to them by management, and each person is evaluated according to how well he has done the task at hand. They work as a group, but not as a team.

A team is also a collective, but as opposed to a group, decisions are shared, the rules are internally established, and the rewards (or punishments) are shared by all.2

According to a blog posting by Shirley Fine Lee,

A great team will have:

1. Members sharing leadership responsibility and rotating other roles as needed.

2. All participating in idea generation, problem solving, and decision-making.

3. Members showing support, respect, and trust for one another.

4. All taking actions and doing work that is necessary to reach team goals.

5. Members managing conflict by confronting issues and inappropriate behaviors.

The best teams display these characteristics in their roles, attitudes, behaviors, and working as group and dedicated individuals.3 Team building exercises consist of a variety of tasks designed to develop group members and their ability to work together effectively.1 There are many types of team building activities that are designed for particular needs. Certain team building exercises can be used to improve communication, problem solving and decision-making, planning, adaptability and trust. There are also more complex team building exercises that are composed of multiple exercises such as ropes courses, corporate drumming and exercises that last over several days.1 Activities such as costume contests on holidays can be considered light exercises, but effective none the less in achieving team camaraderie.

So why is team building important?

The purpose of team building exercises is to assist teams in becoming cohesive units of individuals that can effectively work together to complete tasks.

Making teams more productive is a constant issue for most managers. Productivity is, of course, the essence of what makes businesses competitive, but it is particularly important in times of economic slowdown such as the one we are currently experiencing.2 In other words, team building can have a direct effect on the company’s bottom line.

Wikipedia lists the following in reference to the need of team building.

§ Improving communication

§ Making the workplace more enjoyable

§ Motivating a team

§ Getting to know each other

§ Getting everyone "onto the same page", including goal setting

§ Teaching the team self-regulation strategies

§ Helping participants to learn more about themselves (strengths and weaknesses)

§ Identifying and utilizing the strengths of team members

§ Improving team productivity

§ Practicing effective collaboration with team members1

So what have we learned?

Team building is a process that develops cooperation and teamwork within a work unit. To constitute an effective team, its members must share a common goal and be motivated to use the strengths of each member to achieve their objectives. Through activities known as team building exercises, individuals can practice a variety of techniques such as brainstorming, collaboration, creativity and trust. Current corporate philosophy stresses that each member of a team plays an integral part in the success of the company. The foundation of all team building is having shared goals to which all team members are committed.4

By: Wesley D. Sims

References:

1. http://en.wikipedia.org/wiki/Team_building

2. http://www.allbusiness.com/human-resources/employee-development-team-building/525073-1.html

3. http://www.smallbusinessdelivered.com/fivecharacteristicsofagreatteam.html

4. http://www.wisegeek.com/what-is-team-building.htm

In the business world, the things we DONT say often result in incomplete requirements documentation that can lead to contracts lost, tarnished reputations, emotional anguish, wasted time and wasted money. Fortunately, there are ways we can improve our chances of success.

Imagine you have recently graduated UABs IEM program and have started your own business. You are about to deliver a product to your first customer. You and your team have been working on this project for several months and feel very satisfied that the project meets all customer requirements. Your implementation is impeccable. You present the fruits of your labor only to find out that your customer is not at all happy. It appears some key element is missing. Instead of hearing songs of praise in your honor, youre hearing How could you have possibly missed that very important thing? I thought you were the expert! You immediately pour back over your requirements documentation with the urgency of a mother bear searching for lost cubs only to find out that every requirement has been designed and implemented. Your requirements gathering method was systematically executed and the requirement document was met yet this knowledge is very cold comfort when your customer is clearly not happy. What happened?

The problem is that as people formulate ideas of what they want, much of what is in their heads can remain unspoken. The customer is probably not aware that these ideas are not communicated and probably thinks you should just know. Chip and Dan Heath refer to this phenomenon as the curse of knowledge in their book Made to Stick. Lots of research in economics and psychology shows that when we know something, it becomes hard for us to imagine not knowing it. As a result, we become lousy communicators.

To make matters worse, people actually think they are doing a great job communicating when they are in fact not getting their idea across to their audience. The Irish playwright and co-founder of the London School of Economics George Bernard Shaw lamented, The single biggest problem in communication is the illusion that it has taken place.

The processes of business analysis and requirements documentation are designed to systematically catalog and prioritize what the customer wants from your product or service. But even with these tools it is very risky to rely on people to communicate well enough for the kind of knowledge sharing required for complex projects. Communication of crucial ideas is inadvertently shut down and key implicit (to the customer) requirements are not made explicitly (to you) into the documentation.

The costs of incomplete requirements can be very high. According to the Business Analysis Benchmark Report released by IAG Consulting in 2008, 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. IAG Consulting goes on to list delivering [less
than] 70% of the target required functionality
as a principle cause to such failure.

To avoid the frustration and pains of failure, you need to get the right information from your customer. Jill Richards PMP CSM and founder of Inovacent Solutions, LLC offers the following two creative questions you can ask your customer (Lemen).

1. Often times, at the beginning of a project I will ask the key stakeholders this question (please note that my background is Information Technology, so modify the question for your applicable industry): Picture the first week that this new system is live. It is completed, and your team is using it. They love it! It is working so well, its doing everything you were hoping for. It is great. It is working amazingly well. You are so glad we did this project for you! Tell me why. What is it doing? Why do you love it so much? Why is your team so happy? What problems is it solving, and what opportunities is it creating? Why is it that great?

2. Then, I will ask key stakeholders a similar question, just in a different way: Now Id like you to once again picture the first week this new system is live. Keep in mind Im not trying to panic you, so relax But we have to talk about it to be prepared. Its the first week with the new system, and its a catastrophe! Your team is so frustrated!! They despise this new system, and wish we never did this project! Tell me why. What specific problems are they having? What are the impacts? Why is it that terrible?

These open-ended questions focus on end results, help bring out what is most important to the customer and open up the dialogue that helps reveal those requirements hidden by the curse of knowledge.

Works Cited:

1. Ellis, Keith. The Impact of Business Requirements on the Success of Technology Projects. BusinessAnalystTimes. http://www.batimes.com/articles/the-impact-of-business-requirements-on-the-success-of-technology-projects.html

2. Heath, Chip, and Dan Heath. Made to Stick. Random House, Inc., 2007

3. Lemen, Kestrel. Business Analysts Need Creative Questioning for Better Requirements: What Are Your Best Questions? The ASPE SDLC Blog. 15 Sept. 2010. http://www.aspe-sdlc.com/blog/?p=1355

By: Chris Acree

Applying Project Management

November 11, 2010

EE606 – Applying Project Management- Blog posting by Kimberly Williams, November 10, 2010

Project management consists of defining and planning, monitoring and controlling all aspects of a project to achieve project objectives on time within specified cost, quality and performance. There are several approaches to managing a project, such as agile, interactive, incremental, and phased approaches. Whatever approach is used, consideration should be given to the project objectives, timeline, cost, and the roles and responsibilities of all participants and stakeholders [3].

Successful project selection is the first step in project management. Effective managers project by define and plan their project. They initially define the scope of the project so it will include the areas you are responsible for. Understand the organizations boundaries, look at any potential risk in the project scope that you may not be able to manipulate and try to restrict these or eliminate them from the project areas [4].

Always obtain management support, an if there is authorization to proceed, draft a charter of the responsibilities and scope, which should indicate what will be expected, the general project rules, and how the project will obtain resources to complete the job [2]. Review your organizations policies that govern the way projects are executed, and understand the project selection and approval process. Be sure to converse with management regarding the charter until there is an agreement made.

For project success it is important to understand and document the requirements. Without written requirements statements, there is no way to account for changes and manage customer and sponsor expectations. It will serve as the basis for the plan, for the cost and schedule estimates and it will allow for management for changes as the project progresses [1]. If there are unclear requirements, make assumptions and document them. Use version control for the requirements and manage the changes. If significant changes occur, revisit the cost schedule estimates.

Document a realistic plan by documenting the link between the project scope, description, staffing and procurment estimates, and the schedule and iterate them until it fit the organizational goals. Create a project plan and use it to communicate to the stakeholders the intentions of the project effort. Break the project into phase, incorporate the phase into your project schedule and plan updates to the scope, cost estimate, and schedule before the transition review meeting. Structure the work within each phase into intermediate and lower level milestones and link tasks or deliverable production. Write a break down structure to help map charge numbers, schedules, project metrics, etc. Try to reconcile the project scope, resource budgets, and schedule goals [5].

To build your project team, always develop a staff plan based on your resource estimates of quantities of people required. Select key people for the project team, and speak with each individual to determine their interest level and to confirm their commitment to working constructively and productively on the project [4]. Assess your risk by identifying areas of the project where there is uncertainty where there may be a negative impact and designate these as project risk. Once risks are identified establish management actions to avoid, mitigate, monitor, and manage your potential risks. Add the risk to the project plan and relay them at your management review meetings.

Finally you are ready to execute your project. Organize a kick-off meeting for your project team and make everyone take full responsibility for their project areas, manage the scope, schedule baseline carefully, and make sure the metrics are implemented to monitor all important functions of the project [2].

Reference

1. “Applying Project Management Concepts to R&D.” Eldon Larsen

http://allbusiness.com/management/1001264-1.html

2. “Applying Project Management Skills.” Speech & Language Therapy in Practice. 2006

http://www.speechmag.com/content/files/sattyboyes.pdf

3. Kerzner, Harold and Saladis, Frank P. “Value – Driven Project Management.” John Wiley & Sons, Inc. 2009

4. “How to Apply Project Management Prince 2 – Engaging Senior Management in Your Projects.” David Hinde

http://www.your-career-change.com

5. “Starting a Project.” James Chapman

http://www.hyperthot.com/pm_step_by.htm

Resource Management

November 11, 2010

Introduction

Within a project of nearly any size there are bound to be many moving parts to keep track of. While many of the components, such as scope, deadlines, budget, etc., should remain mostly fixed that is not always the case. Having to deal with this complexity has led to all sorts of methodologies and best practices being developed to effectively deal with the various facets of project management.

Within this posting we will examine one of the key components of project management: resource management.

What is a resource and why would I manage it?

The dictionary defines a resource as a source of supply, support or aid that can be readily drawn upon when needed.[1]

Not included in the dictionary definition are these important facts: resources are only applied in order to gain some kind of benefit for someone and resources are almost always limited in some form or fashion; be it quantity, cost, availability, or some combination of these.

In the context of project management most tend to immediately think of employees as the resource but there are actually many different types of resources to deal with in a project such as financial resources, inventory, technology and yes, people. Additionally, not all resources are tangible; with the advent of technology, more and more resources are becoming intangible or virtual.[2]

Because of the inherent scarcity of project resources it becomes vital to efficiently allocate, utilize and monitor them. This is where the idea of resource management comes into play.

Considering these factors, it is imperative to have concrete data and trustworthy estimates of the resource needs to ensure that decision makers within an organization fully understand what is required and can be convinced to dedicate all the necessary resources to the project.

OK so how do I manage resources?

When it comes to actually managing the resources in a project, a multitude of plans, schedules and other documents have been created to track the different aspects. Many of these tools have been rolled into various project management software suites such as Microsoft Project.

Which of these tools will be needed and which will work best will, of course, depend on both the specific project and the organization but below are just a few of the key documents/processes that are frequently seen with nearly any project:

· Resource Plan – Put simply a resource plan is a summary of all the resources that will be needed to complete a project. At a minimum it should include estimates on the amount of labor, equipment, and materials required. It should also identify the specific roles or purpose for each resource in the project. This document contains the hard data needed to get a commitment of resources from the project sponsor and will also be used to continue further planning such as scheduling, budgeting and leveling of resources.[3]

· Resource Calendar – Just as it sounds, this is a calendar that is used to track the availability of each resource. It contains all of the working and non-working days in the project and information on which resources are used when. This becomes useful when trying to identify which resources may be overutilized or when a shortage of resources may occur.

· Resource Leveling – Perhaps one of the toughest aspects of resource management is trying to balance the utilization of resources; the ideal situation is that the demand for resources never exceeds supply and vice versa.[4] In order to achieve this goal it is important to be able to identify the dependencies between tasks as well as the availability of resources and attempt to level out the allocation so that no resources are overutilized while others are underutilized. While it will be possible to smooth this out, it is rarely possible to reach total equilibrium. Software suites like Microsoft Project typically have the capability to help automate resource leveling which is difficult to do manually.

So what if I don’t bother with all this?

Without resource management, there is no way to accurately estimate what resources you’ll need and how many nor will you be able cope with any unexpected events that can delay a project or halt it all together. It’s a given that complex projects will have many variables to keep up with but resources simply can’t be ignored.

References

1. Resource – Definition and More from the Free Merriam-Webster Dictionary – http://www.merriam-webster.com/dictionary/resource

2. Resource (project management) – http://en.wikipedia.org/wiki/Resource_%28project_management%29

3. Karkhanis, Santosh. Resource Plan – http://www.karkhanisgroup.com/consulting/management/project-management/project-management-activities-project-initiation/project-planning-activities/project-planning-activities-1.html

4. Project Management Knowledge – Resource Leveling – http://project-management-knowledge.com/resource-leveling/

Author: Robin Martinez

In most typical modern organizations, be it a smaller company of 30 or a large world-spanning corporation, meetings are generally reviled by average employees and cherished by management (Singer). In a smaller company it’s very easy for a manager, or engineer for that matter, to call impromptu meetings on a whim to go over project status, the help desk ticket queue, or a host of other items. Working in a smaller company, I see it first-hand. It’s extremely disrupting to stop work and sit in meetings peppered throughout the day. In larger corporations, it’s typically the organizational structure that perpetuates meetings as various departments in disparate geographic locations try to come to some consensus regarding everything from small personnel issues all the way up to far-reaching topics like overall corporate strategy. Meetings breed more meetings for follow-up on the original meeting’s action items, especially when those tasks are assigned to multiple department heads as communication must then be facilitated across departments and rolled back up to management in yet another meeting (Malik). It’s a truly vicious cycle in most cases and can completely destroy project momentum. So, how to stop the madness? Here are a few tips on reducing extraneous meetings and making the ones you must organize more effective for all involved.

1. Empower Your Team. Let those closest to the needed decision make the call and create an environment where team members can approach one another for buy-in without the need for calling the entire team or multiple department heads together in a meeting. Build trust in your team to make a good call (Singer). All too often we get bogged down in the decision-making process over minutiae that could be resolved among team members. If an issue or change request needs to roll up into a team or inter-department meeting, then do so, but make sure you can’t resolve it outside of a meeting.

2. Find Other Ways to Communicate. Form a living ‘team or organization memory’ using tools like wikis, blogs, or even whiteboards (Khawand). Collaboration tools are manifest and even the smallest organization can afford them – i.e. it doesn’t have to be SharePoint, even though that’s included free with any Server 2003/2008 purchase. In my group, we use our ticketing system notes and a wiki to document our clients and any related issues. All we ever need to do is look at our client history and we can usually tell what’s going on without having to take up time talking or meeting with the team. Of course, this requires discipline in keeping your documentation up to date, but the payoff in time saved is well worth it.

3. Prepare an Agenda. It may seem obvious, but time and time again I participate in meetings where there is no set agenda. An effective meeting chair will think through the entire meeting, formulate what they’re going to say, and keep the agenda simple and concise (Malik). Do not allow last minute changes or permit attendees to hijack or derail the agenda with unrelated miscellaneous items (Malik). Without an agenda and a strong chair to back it up, most meetings will run over their scheduled time and sometimes degenerate into social gatherings wherein the original intent and purpose of getting everyone in a room together disappears. If you’ve all come together to discuss the status of projects, then stick to it. Don’t wander off topic with the newest gadget or tangents on the latest personnel issue.

4. Keep Distractions at Bay. This point is especially problematic now with the proliferation of smart phones and the shift to a mobile, laptop equipped workforce. During several meetings I’ve attended, both internal and client-facing, you can look around the table and see a good 60% of the attendees checking email on their phones or absorbed in other work on their laptop. Invariably, they don’t remember what was said and they have to come ask someone later which renders the effort to get everyone together for the original meeting a waste. Ask attendees to focus and leave their mobile devices aside to avoid additional meetings and unnecessary follow-up (Trapani).

Start steering your organization toward a more fulfilling and productive environment by adhering to the principles listed here. This is by no means an exhaustive list, so be sure to check around for additional tips as there are many. If all else fails, purchase a meeting clock at www.bringtim.com and watch the dollars tally as the meeting wears on – that should change some key minds fairly quickly.

-Mike Gann

References:

Khawand, Pierre. “Reduce Meetings, and Make Them More Effective.” businessweek.com. 10 Oct. 2010. http://www.businessweek.com/smallbiz/tips/archives/2010/10/reduce_meetings_and_make_them_more_effective.html

Malik, Fredmund. “Managing Performing Living: Effective Management for a New Era.” books.google.com. 2006. http://books.google.com/books?id=5TMGEkmmQ7EC&pg=PA246&lpg=PA246&dq=reduce+number+of+meetings&source=bl&ots=ON604RpTNs&sig=_p5f0Da4DsOJsRZfCygdtEpsh8w&hl=en&ei=FsHWTO_8GcL7lwezk8WDCQ&sa=X&oi=book_result&ct=result&resnum=8&sqi=2&ved=0CDUQ6AEwBw#v=onepage&q=reduce%20number%20of%20meetings&f=false

Singer, Adam. “How And Why To Reduce Meetings.” thefuturebuzz.com. 9 Sept. 2010. http://thefuturebuzz.com/2010/09/23/reduce-meetings/

Trapani, Gina. “Extreme Ways to Shorten and Reduce Meetings.” blogs.hbr.org. 20 Jul. 2009. http://blogs.hbr.org/trapani/2009/07/extreme-techniques-to-shorten.html

Change Management

November 11, 2010

EE606 – Change Management – Blog Posting by Dan Prabhu, November 10th, 2010.

Change management and project management are similar in their approach; they are both used to complete a successful project. Both use processes and a set of tools but the one key difference is, a project manager applies project management on a project, which means a single source can do the activities”. The main approach to change management is to improve the organization by altering how work is done. The change process utilizes tools and manages people to achieve the required business outcome. [2]

The key to change is to satisfy the stakeholder by involving them in the process and to keep them informed. Recognizing that communication is the key to implement change and participation can influence the outcome of the change. Change process fair better when people who are involved and actively have direct influence to an outcome of a particular change. Even when people are not actively involved but are represented by someone they respect, they are more likely to approve the change requirements. [1,2]

Another aspect of change is support and authority according to Steve Slusarenko. Slusarenko a PMP states that if a “project manager is seen, or perceived, to be without the support of senior management, he will not be given the authority to institute change from peers and subordinates, the project will fail”. Support from senior management which has the final say so if change is to be implemented but support from stakeholders and people involved is also a must. [5]

Change management is a process which is implemented. A change manager will facilitate assessment, create a change management strategy and develop change management plans, however there are other groups who are also involved: these include the project team, senior leaders, managers and supervisors and finally the employees. The project team consists of resources on a project which comes up with a strategy for a specific change which a group is impacted. The visible group is the senior leaders, who contribute the most to a project. The senior management are the once who are active throughout the project, who also communicate with managers and the business to arrange a sponsorship for the change. [4]

Managers and supervisors are the communicators with the employees and their direct reports. The main job of this team is to conduct coaching secessions, analyze and manage resistance and provide feedback to the change manager. The employees are the once who are affected by the change and provide the feedback and reaction to the change management. The project team coordinates the change management process to the project management plans. [1,4]

Following tools and components are encompasses change management:

  • Change management process
  • Readiness assessments
  • Communication and communication planning
  • Coaching and manager training for change management
  • Training and employee training development
  • Sponsor activities and sponsor road maps
  • Resistance management
  • Data collection, feedback analysis and corrective action
  • Celebrating and recognizing success [3]

Finally it’s important to know what is and what is not change management.

· Change management is not a stand-alone process for designing a business solution.

· Change management is the processes, tools and techniques for managing the people-side of change.

· Change management is not a process improvement method.

· Change management is a method for reducing and managing resistance to change when implementing process, technology or organizational change.

· Change management is not a stand-alone technique for improving organizational performance.

· Change management is a necessary component for any organizational performance improvement process to succeed, including programs like: Six Sigma, Business Process Re-engineering, Total Quality Management, Organizational Development, Restructuring and continuous process improvement.

· Change management is about managing change to realize business results.[4]

References:

1. 1. http://www.projectsmart.co.uk/making-change-happen.html

2. 2. http://www.change-management.com/tutorial-cm-basics-who.htm

3. 3. http://www.change-management.com/tutorial-change-process-detailed.htm

4. 4. http://www.change-management.com/tutorial-defining-change-management.htm

5. 5. http://www.maxwideman.com/guests/change/abstract.htm (Steve Slusarenko, PMP)

Of the hundreds of projects we work, the most common problem is the failure to meet expectations. We hear “this is not what I want” (customer); “but this is what you asked for” (supplier); “but this is not what I need”[1].
I was under the impression that project management is all above applying common sense to project work. “Common sense is not commonly practiced. I have also heard many people say that project management is nothing more than organized common sense. Maybe that’s why many projects fail. Common sense is just not applied. That may be one of the problems, but it isn’t just the lack of common sense that creates problems and in some cases causes failure; it’s a lack of the necessary combination of learned skills, common sense…”[2]. Good project management ensures the success of a project.
Project Management is all about efficiency and methodical process. To achieve efficiency we do need some methodical streamlined process, and to achieve effectiveness we do need definition of objective and its quality. We have simple ‘to do lists’ to achieve efficiency and effectiveness in project management. “Check them out, check them off and congratulate for well done.” [3].
Start out: Make sure that your customer specifies their requirements in detail and recognize exactly what it is that must be presented, to whom and under what circumstances. Make it proper, write it up orderly and get them to sign it off. This document will turn the ground upon which to evaluate success.
Customers: Engage customer to work with you as part of the team. Get them active in the analysis and preparation, as well as implementation. You don’t have to look for their approval, just keep them knowledgeable. The more you involve them, the greater their level of buy-in and the lighter it is to deal with their anticipations.
Team: Hire the finest people you can afford. Spend time to find the proper individuals. It will keep you time down the track. Good people are easily to motivate. Present them the visual sense and how they can make it materialize. Motivate and resolve conflicts between individual members of the team. Trust and believe in them. Let them feel appreciated. They will work fantastic.
Scope: Define goals and scope clearly; ensure that everyone on the team understands what is expected of them during the project. Just authorize modifications to your project scope if there is no affect on the timeline. Make your customers commendation to essential scope converts first and then have their buy-in to expand the deliverance dates if you want to.
Communication: Pass the information at proper time and make sure you let everyone educated. Formalize your status calls with the customer. Create Weekly Condition Reports and lead frequent team conferences. Use Project Management Templates to spare you time.
Milestones: Set milestones for smaller steps. By doing this you will focus on short term goals for delivery- provided keep the long term objectives in mind. Separate your project time frame into “Milestones” which are attainable parts of job. Put delivery deadlines to your milestones and try to deliver on each deadline, no matter what. If you’re late, utter to your customer about it as earlier as possible.
Time frames: Keep your delivery time frames low and realistic. Never correspond to long time frames. Separate the project into “mini-projects” if you need to. Keep all mini-projects to less than 6 months. This keeps everybody motivated and concentrated.
Deliverables: The ultimate measure of a successful project is deliverables. A project is usually broken down into several deliverables, as each deliverable is through; deliver it formally over to your customer. Get them to sign an Acceptance Form to say that it meets their expectations. Only then can you check every deliverable off as 100% complete.
Quality: It means meeting or exceeding customer expectations at a cost that represents a value to customer. Whether it is project quality or deliverables quality, there should have some form of quality check list. Continue the quality of your deliverables as higher as possible. Forever reexamine quality and never let it slip. Implement “peer surveys” so that team members can survey each other’s deliverables. Then put in place external surveys to ensure that the quality of the solution fills your customer’s wants.
Risk: Work on the risks areas and issues as soon as they are identified. Prioritize and resolve them before they impact on your project. Revisit them often. Take pride in keeping hazards and issues to a minimal [4].

No matter what, stick with the Project Management processes in order to stay the course and keep both the customer happy and team engaged. Project success is much more likely if you follow a proven process and utilize efficient and effective communication and mixing in interesting technology.

By: Vishnu Thogaripally

References:
1. http://www.bcs.org
2. 7 Habits of Highly Effective People author Dr. Steven Covey 3. http://www.gantthead.com/checklists/
4. http://www.wikihow.com/Make-Your-Business-Project-a-Success 5. http://www.stellman-greene.com/aspm/
6. http://www.berr.gov.uk/files/file40647.pdf
7. http://projectmanagementblog.com
8. http://www.maxwideman.com/

Why does Projects fail even when we have PM strategies in place?

The project which I want to mention here is a LOB initiated project, which I am naming it as PROJECT X, because of security reasons, was a 1 year 3 months project and it was approved by the Capital Expenditure team. The project’s objective goals were to identify each officer’s portfolio and make decisions on his/her incentives pay. The accumulative performance for each employee over goals/budget was calculated by the quarter. This is a quarterly review process to evaluate employees working in a banking world. The incentive pay for the employees is one of the most complex and sensitivity in the Banking world. Any unclear reported incentive could cause quite a few confusions between the Corporate LOB team and the officers on the field.

The primary reason for choosing this topic is to find the reason why PROJECT X failed. The cost identified for Project X was estimated over 2 million dollars and was assigned to vendor driven PM team and a Development team. After the project demise the aftermath cause the company approx 2 million dollars and also eliminated some FTE positions.

As investigating project in details, I was able to find the main problem which caused the failure. Though I came across different variety of reasons which could have caused the project fail, the main and foremost problem was the waterfall approach the PM team adopted. I have met with business stake holders for this project and couple of developers (which is in my team now for the same project re-initiated) to know what caused the demise. As per the business stake holders, there was only one initial review occurred for verifying the Business Requirement Document and from there for over 9 months there was no communications between the PM team and the Business. LOB called for a project review meeting after 9 months to review the project status. And they found out that the project was incorrectly design. The translation of BRD to the technical specification itself was wrong. This really created Havoc between the LOB, PM and development team. As usual the blaming sessions started among the LOB, PM and the development team. After further review thru the BRD, it was clearly stated in the requirements by business partners of what they want. In the initial project evaluation, the Business and the PM team have agreed on the BRD but somewhere it lost the business requirements translation. The translation was lost because after the project was kicked there were changes in the PM team, like adding new team members, and the contents from the BRD were not transferred properly to the new replacements. This caused the communication problem between the PM team and the Development team. The development team along with the PM team created the Technical Spec which reflected the BRD but not understanding what business really need. So the end design was a flaw. Business stake holders decided to dismiss the current PM team and development team because of not seeing any progress or deliverables. They decided to put a new team in the process to complete Project X on its last remainder six months period.

At this time, we had a new PM team and the new development team from the different vendors to get the work done in the remaining 6 months. Business partners tried to extend the project more than 6 months but the management did not agree to the proposal. The PM’s along with the Development team started to do the re-design and rework to deliver the project in the remaining 6 months. Unfortunately, there wasn’t enough time to turn the project around from scratch. The team even tried to patch the wrongly designed model. In my opinion, it was a mistake to incorporate the old business requirements and failed to comply with new business requirements.

My main findings for the project’s failures are described below. This is with respect to the Main team (PM and development) which took the initial development of the project in the first 9 months.

  1. Waterfall approach for the project. No verification check points with the Business Stake Holders for approval at each stage of the project.
  2. Design of the data model was done with no proper understanding of the BRD and never got approved from the Business.
  3. Constantly changing Consultants, both PM’s and Developers. This resulted in no proper transfer of knowledge between the PM and developers when they are moved out of the project and replaced by new ones during the project.

Assignment_Bryan_11092010.doc