A Critique of Ashok Kumar and Vinay Goyal article “Software requirement analysis enhancements by prioritizing requirement attributes using rank based Agents”

A Critique of

Ashok Kumar and Vinay Goyal article

“Software requirement analysis enhancements by

prioritizing requirement attributes using rank based Agents”


Table of Contents:

Abstract

Introduction

AOP in the Project Environment

Related Work

Agent Oriented Software Application with Scope and Requirements Gathering

Conclusion


Abstract:

Software using agent methodologies is an evolving method growing very rapidly in software development projects.  Agent oriented programming (AOP) is a paradigm where the construction of the software is centered on the concept of software agents.  The difference between object oriented programming (OOP) and AOP is that AOP has externally specified agents at its core whereas OOP is object oriented providing methods with variable parameters embedded within.

Systems composed of interacting autonomous agents suggest an encouraging software approach for developing and managing applications projects in complex environment. However, this multi-agent system standard introduces a number of new concerns when compared with more customary methods to software development. As such, new analysis and design methodologies, perhaps even new tools, may be needed to effectively create such systems.

Professors Kumar and Goyal conducted experiments to determine how effective AOP was in the project environment in determining user requirements. Their contention was that AOP is very helpful in the Software Development Lifecycle (SDLC) showing improvements in cost and effort. Professors Kumar and Goyal feel that the autonomous and reactive nature of AOP makes it possible for designers to visualize a solution. Their experiment aimed to prove this contention true. The following paper discusses their work and how it applies to the integration of scope, requirements gathering and time in managing projects.

Introduction

Agent oriented software; software that is capable of thinking and making decisions based on past events has been coming of age in the gaming world for many years. Now, it is being developed for use in the everyday business world, especially for use in developing business applications. But can it work in determining scope and requirements for business application projects?

Professors Kumar and Goyal experimented with agent oriented, which is growing very rapidly, to determine its effectiveness in determining requirements in application development. Software development industries have invested huge efforts in this domain and results published by many of them seem positive. This paper examines their work and compares how effective it may be in everyday project scope development and requirements gathering.

AOP in the Project Environment

The concept of AOP and the idea of centering your software on the concept of agents were first used by Yoav Shoham and his studies around artificial intelligence (AI) (Shoham, 1993). He used only single parameter agents at first that were specific to his studies. Shoham would later develop theories around game-theory and has won awards around his studies concerning the intersection of computer science, game theory, and economics, particularly in multi-agent systems. Kumar and Goyal are attempting to expand on this theory by putting it into practice to determine if there would be any improvement in the Software Development Lifecycle (SDLC). They point out that past studies show an improvement in the process and that agents have helped minimize project costs (Kumar, 2011).

By fine tuning agents and what is called the SDLC process-state-plug-in for two-way communications the result is that the agents can improve on organizing resources in such a way that helps to better utilize time requirements. Kumar and Goyal conducted such an experiment specifically to improve the requirements analysis process. The agents would sense the requirement environment and deliver a checklist of what it considered to be important requirements. This functionality goes along with the idea of artificial intelligence (AI) in that we can set programs to not only identify parameters when they’re presented; we can also make it so the program learns by storing information it can draw from so that it can make suggestions based on prior events.

The objective of an agent-based model (ABM) is to search for explanatory perception into the combined behavior of agents (they’re not necessarily “intelligent”) following simple rules, usually in natural systems, rather than in answering specific practical or business problems. Typical topics for ABM’s in MAS are online trading approach, disaster response or modeling social structures.

Related Work

The analysis process for using agent-oriented analysis and design involves using the GAIA Methodology. GAIA is made up of the following stages (Wooldridge, 2000):

  1. Any protocols should be identified and associated with each role. Protocols show the interaction that could occur between each role
  2. Identify individuals, departments, or organizations as key roles model that occur in the system with a description of each
  3. Elaborate on the role model using the protocol model. This should produce a fully elaborated roles model documenting the key roles in the system, their responsibilities and permissions together with the protocols and activities of each role

From these and other experiments engineers have been able to develop what are known as an autonomic computing mechanism that is capable of self-configuration, self-organizing; a kind of self-adapting software with the ability to use available information about its ever changing environment to change its decision making process. It stores event outcomes in a database using it to judge future events in order to make a decision.

Agent Oriented Software Application with Scope and Requirements Gathering

Part of the problem with using rank based agents is whether these agents can be flexible enough to meet the needs of business. Flexible agent based architectures have been experimented with by software developers and is considered the foundation for many next generation systems. But the success of these agents will very much depend on how they’re fitted into a business environment and they’re ability to change with that environment (Kerzner, 2009). While lining up specific requirements in an online form to roles, responsibilities, and permissions to ABM’s would make gathering requirements much easier, it cannot take the place of intuition. Part of the requirement for being a project manager is having a god business sense and intuition about what will work and what won’t work (PMBOK, 2013). While Kumar’s work certainly shows promise, as their test results seem to bear out, it’s difficult to see how these tools can be used in determining overall project requirements.

One part of managing projects is determining which resources will be used and when. While the ABM’s can help in determining skill level needed and matching to specific tasks, it cannot determine if that resource will be a good fit into the project team. Often this determination is a purely gut feeling on the part of the project manager.

Conclusion:

Can agent based methods be applied to all aspects of scope development and requirements gathering thus saving time and money? Yes, it can be. Currently it would seem to work well with identifying and matching applications requirements to roles and responsibilities. It would prove to be especially effective when used to determine security requirements with role permissions, especially in today’s security crazed world. But even in everyday business transactions carried out online in the business world, the ability to develop applications using ABM would help to save a tremendous amount of costly planning time. The real question here is will companies spend the time and money to develop such methods. Only if it was proven to them that it would cut development cost drastically would implementing ABM’s be considered. As with any new technology, it will take many years for full realization.

References:

Kerzner, H. (2009). Project management: A systems approach to planning, scheduling, and controlling. Hoboken, NJ: John Wiley & Sons.

Kumar, A., & Goyal, V. (2011). Software requirement analysis enhancements by prioritizing requirement attributes using rank based Agents. International Journal of computer science and information security, 9(8).

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.

Shoham, Y. (1993). Agent-Oriented Programming. Artificial Intelligence. doi:10.1016/0004-3702(93)90034-9

Wooldridge, M., Jennings, N. R., & Kinny, D. (2000). The Gaia Methodology for Agent-          Oriented Analysis and Design. Autonomous Agents and Multi-agent Systems.

Team Building – A Critique

Trust has been shown to be of utmost importance to delivering projects successfully. Without even the best planned projects can fail. Without trust the project is doomed to continually fighting battles that threaten the team’s ability to deliver a quality product/service on time and within budget.

Introduction:
Dictionary.com (2015) defines trust as a reliance on the integrity, strength, ability, surety, etc., of a person or thing; confidence. It is a confident expectation, a hope that someone or something is going to deliver as promised On a project team the members of the team fully expect and trust that the project leadership to manage the project efficiently. But it’s a trust that has to be earned, and not just by the projects management team; it has to be earned by everyone in order for the project to be successful.
Valerie Lynn Herzog conducted a study: Trust Building on Corporate Collaborative Project Teams (Herzog, 2001) in which she determined that trust is a huge factor in the successful completion of a project. But, there is a process the group needs to go through in order to build trust amongst the team members. Ms. Herzog’s paper concentrates on the team collaborative trust building because many times teams are chosen and the team only has the opportunity to work together, many times without really knowing one another.

Team Building:
Herzog’s study centers around building trust through collaborative efforts; such as shared processes, honest communications and just getting along (Herzog, 2001). She had found that while upper management many times have the choice of whom they will work with, team members are usually assigned to a project with little choice but to accept the assignment (Herzog, 2007).

I know this to be true in my assignments. Even as Project Manager, I’m generally not given the choice of which projects I will be managing. In fact, I’m rarely given the choice of which resources are assigned to my projects.

Research has found that levels of trust are based on the collaborative team member’s perception of themselves, of other team members, and of other stakeholders in the project (Herzog, 2007). These trust levels really embody the key behaviors that are needed for project or team success: Mutual trust; Interdependency; Accountability; valuing individual differences; Transparency, and learning and recognition (Wong, 2007). Without these, even a well-planned project could be doomed to fail because no one trusts each other. Without these key behaviors; particularly mutual trust, a project is usually doomed to failure, or worse, a long agonizing path to success.

Perceptions of Team:
In the study Herzog interviewed 20 participants from 4 different IT projects. The participants had positions on the teams ranging from Senior Manager to Junior Technical Designers. The participants included Project Managers, Business Analysts, Programmers, Senior Managers, and Program Managers.
Perceptions of different issue or deliverables in the project appear to be universal. For example, the charter was seen as a lot of nice to haves but not to be taken seriously since no one really looks at once its produced (Herzog, 2007) The reality is that the Charter is the most important document in a project. It contains the project purpose, high level requirements, the project scope (PMBOK, 2013). Part of the trust has to be delivered through the charter. Team members like to feel that what they’re doing has meaning. Without any meaning then the team wonders why they’re doing what is being asked of them.

Collaborative Sharing:
Using collaborative sharing helps to bring the team together, especially in the beginning of the project. Each individual team member comes into the project with their own perception of what is involved. And, most likely, with how to solve the problem or to create the solution that brings the project to a successful conclusion. Imagine that you have a team of 20 in a room and each one has the solution. The question is: how are you going to bring each of these individual solutions together as one solution?

Herzog found that creating that trusts requires formal processes and that these processes should occur frequently (Herzog, 2001). I have found that one collaborative process with the team is to specifically review the Project Charter so that they understand what is being asked and they see there is high-level support for the project. I also have found it to be a great way for the team to build trust in each other by sharing the process of review together. The team begins to get to know one another as they share their thoughts on what the Charter means to them. As they get to know one another they begin to trust and to form bonds that help to create a working relationship. Collaborative sharing helps to build a solid foundation in which to drive projects to a successful conclusion.

The solution to the above question was to begin with open and honest communications. As a team, together you decide how the team will communicate in an open and honest way. Building open and honest communications builds a trusting environment for the team and leads to successful projects (Herzog, 2001).

By defining the communications processes we can begin to realize other team member’s motives for the solutions they bring to the table. By understanding a team members motives we can better understand their responses to questions or their ideas when the present them. By encouraging team members to openly respond to inquiries or questions we could also be opening the flood gates to better solutions to the projects goals. Trust has to happen between two people first and then grow from that point. As that trust grows, people feel free to speak up, other team members begin to open up and trust other team members. The goal, hopefully, is that trust becomes contagious, as trust makes for a better work environment.

But trust needs to be maintained on a continuous basis. It’s not a one shot and done deal (Herzog, 2001). Trust can be lost at any given time for a lot of different reasons. A team member could show an indifference to the team, not care if their held accountable or not. A team member could decide that their solution is better than what the team agreed and they start to act independent of the team. Here the team needs to bring everyone together to reassert the ground rules and clearly define the authority level the team abides by (Wong, 2007). Clearly, the process of building and maintaining trust is an ongoing process.

Conclusion:
Trust has been shown to be of utmost importance to delivering projects successfully. Without even the best planned projects can fail. Without trust the project is doomed to continually fighting battles that threaten the team’s ability to deliver a quality product/service on time and within budget. By sharing collaborative processes and conditions amongst the whole team on a continuous basis the team and the project will benefit. Collaborative sharing will help to build the trust necessary to bringing a successful conclusion to the project.

References:
Dictionary.com. (2015). Trust | Define Trust at Dictionary.com. In Dictionary.com. Retrieved from http://dictionary.reference.com/browse/trust?s=t
Fleming, Q. W. (2003). Project procurement management: Contracting, subcontracting, teaming. Tustin, CA: FMC Press.
Herzog, V. (2001). Trust building on corporate collaborative project teams. Project Management Journal, 32(1).
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Wong, Z. (2007). Human factors in project management: Concepts, tools, and techniques for inspiring teamwork and motivation. San Francisco: Jossey-Bass.

Project Leadership

Successful projects are usually the result of strong leadership. The question arises as to what is considered, or what does it take, to be a strong project leader. Especially in today’s world of project teams made up of people from cultures around the world. This paper will examine the many different aspects, interpersonal skills and qualities of what it takes to be the leader of a successful project in the IT world.

Abstract

Successful projects are usually the result of strong leadership. The question arises as to what is considered, or what does it take, to be a strong project leader. Especially in today’s world of project teams made up of people from cultures around the world. This paper will examine the many different aspects, interpersonal skills and qualities of what it takes to be the leader of a successful project in the IT world.

Introduction

Project Managers (PM) are very unique people. The expectation is that they bring their projects to a successful conclusion with hopefully just enough resources, money, and time. The expectation levels are pretty high and the pressure can be extreme. They’re asked to take a huge unknown and make it all work together to produce a known. They are the boss of no one; yet are expected to get people to do what needs to be done and are held responsible if they don’t succeed. They have to bring together a group of people who have likely never worked together before and make it so they are a finely tuned engine with all cylinders firing in unison. Depending on the size and nature of the project, that could be a lot to ask of any one individual. It would take a special kind of leader.

Leadership is no longer limited to one or two executives at the top of an organization. There are many different levels of leadership in any company, especially in today’s global economy where resources specialize in a given area of business. Everyone in the company must be a leader if the organization is to survive and thrive (Tichy & Cohen, 1997). Without good leadership, nothing works. Projects have been known to get totally out of control because there was no one leading the group. And even if there is a leader, if they’re weak, the project team will run all over that person.

Leaders are not born leaders; leadership is a discernible set of skills and abilities. Granted, some people are better at managing than others, thus seeming to so many to have been born a leader. But like everyone else, they learned and practiced to become skillful at leading.

Leadership is a relationship between those who aspire to lead and those who choose to follow. Not all of us can or want to be leaders. Sometimes the relation

ship is one-to-one; sometimes it is one-to-many. Regardless of the number, leadership is a relationship between leaders and followers.

But amongst all of the traits a leader needs there is one that has to be earned and it is the one most admired; personal credibility. Without personal credibility there is no foundation of leadership. Personal credibility brings with it trust; we want to believe in our leaders, have faith and confidence that they believe in the direction we are all going. The team has to believe that the PM has the end goal in mind.

PM’s need to have a combination of the above mentioned skills and abilities in order to be good leaders. First amongst these skills are people skills. Next is, depending on the project, technical skills. Technical skills really depend on the project. If it is IT or other highly complex project then technical skills helps in bridging the trust factors of the team (Verzuh, 2012). If the team doesn’t have faith in your technical skills, or at least your ability to understand what they’re doing, they begin to believe you cannot lead them to the end goal of the project.

Other interpersonal skills include leadership, team building, motivation, communication, influencing, decision making, political and cultural awareness, negotiation, trust building, conflict management, and coaching (PMBOK, 2013).

PM’s have to be able to think quickly on their feet when making decisions, sometimes by themselves, but more often with the project team as a whole. They get much of this ability to think quickly from the knowledge and experience they have gained from many years of practicing their trade. Without the education that experience brings us we would not be able to be leaders in this new world.

There are five success factors every project has to meet in order to be successful: Agreement amongst the team as to the goals of the project; a plan with a clear path to completion along with clearly defined responsibilities that can be used to determine progress in the project; continuous effective communications understood by all involved; controlling scope; and management support (Verzuh, 2012).

Getting everyone involved in the project to come together on all five factors is the PM’s job. This paper will discuss the various interpersonal skills needed to successfully bring these factors together and how they apply to the art of Project Management.

Interpersonal Skills

There is no doubt that the best PM’s are also exceptional leaders. They inspire, they bring people together by giving them the vision of what’s down the road, people trust them, and they achieve countless things. To successfully lead a project to completion requires a strong leader with people skills in leadership, teamwork and team behaviors, decision making, problem solving, and conflict resolution. Without these interpersonal skills the project will lack strong leadership and direction which could cost the organization tremendously.

There are three skills, broadly speaking, that good leaders should have:

1.    Technical skills because the team will trust and believe in you if you can participate one-on-one with them in finding a solution; or at least can talk the talk and walk the walk. In the IT world it’s knowing programming, it’s knowing how the pieces of the system fit together in order to make it work. The team wants to know that if need be, you can make it work on your own.
2.    Human skill knows how to work with people. It’s very different from technical skill which has to do with working with things. These skills allow a leader to work with people to help them achieve their goals which helps the project achieve its goals. People skills allows a leader to work with groups of people, especially useful in project management since the object is to get a group of people to work as one towards a common goal.
3.    Conceptual skills involves possessing the intelligence trait as it deals with the ability to work with ideas and concepts. It is central to creating the vision and plans for the project and conveying those thoughts effectively to the team and stakeholders.

Good leaders need to possess a certain traits like intelligence; basically the ability to express ones-self verbally, perceptually and with sound reasoning brings people to trust in your ability to lead. They need to be self-confident. Self-confidence is the ability to be certain about ones skills and competencies. This includes self-esteem. But a good leader is not arrogant. Influencing others is part of being leader and having the self-confidence to influence allows the leader to feel that their attempts to influence are correct and good for the project. Integrity is highly important because it is the quality trait of honesty and trustworthiness. Leaders who adhere to a strong set of principles taking responsibility for their actions exhibit integrity. Sociability is the trait of seeking positive pleasant social encounters. Good leaders like to talk with people, especially in intelligent stimulating conversations. They are polite, sensitive to others needs, outgoing, tactful and diplomatic (Northouse, 2004).

Leadership

Leadership involves concentrating the efforts of a group of individuals and moving them toward a collective goal, empowering them to work as a team. Leadership is the talent to get things done through others. It’s very much like herding a bunch of cats. Respect and trust are keys of actual leadership. Fear and compliance only lock the door to future cooperation. Although important in every project phase, good leadership is critically important during the initiation and planning phases of a project. This is the time to bring the team on board by telling them the importance of the goal, using that vision to motivate and inspire a group of individuals to come together formulating a team to achieve success. Good leaders always have the end in mind.

All through a project, the PM has to establish and reinforce the vision and strategy by continuously communicating the message. This communicating helps to build trust; build team; influence, mentor, and monitor project and team performance. After all, it is people, not plans that complete projects. The PM, by inspiring others to find their voice, keeps the goals and objectives front and center. A successful project is a result of everyone agreeing on what needs to be done and then doing it. From initiation to closing, the project depends on the willingness of all involved to come to agreement, to synchronize action, to solve problems, and to react to changes. Communication amongst everyone is all that is required (Verzuh, 2012).

Team Building

Team building is the process of helping a group of individuals to work together as a cohesive unit, to work with their leader, to work with external stakeholders, and the organization. In the end, good leadership with good team building makes teamwork. PM’s have to remember that running a project is not a one-person effort; it takes a team to complete a project.

Team building really does require all the interpersonal skills a PM can muster, as well as the five success factors for a project. To know and like a PM is to trust them. It’s not likely the team will trust their leader if they don’t really like him, they can’t really like him if they don’t know him, and in the end they won’t trust him if they don’t like or know him.

A project team is a group of people with complementary but diverse skills and experiences who are asked to work together to accomplish the goals and objectives of the project. The purpose of the team is to develop and execute a work plan that will meet the goals and objectives of the project. Everyone on the team needs to be committed and dedicated to the same thing: meeting the goals of the project. Although the goals may be same, how the team elects to execute the work plan is variable.

Team-building activities consist of a series of tasks that establish the goals of the project, clearly define the roles and responsibilities of each team member, and establish the procedures and processes the team will work under.

Some of these processes include how the team will communicate, how it will interact with each other in meetings; the PM needs to lead the team to agreement on establishing the rules for conflict management. Establishing these rules allows the developing of an environment in which the team can work. Part of developing a team environment involves handling project team problems and determining how these issues will be discussed. The PM puts these processes together with their team because the PM knows that the team needs to take ownership and have buy-in for it to work.

Team building helps build commitment from your team. They have to choose to become a member of the team. The PM cannot make them commit, the individual has to decide. The PM, as a leader, has to figure out what is the best way to get that true commitment from you. He has to figure out how to empower you to decide to commit to the project, its goals and its objectives. Some people prefer committing to a team rather than as an individual; it makes it easier for individuals to join. Some people just have trouble committing to a decision except when in a group. Some call this group think where one individual does all the talking and everyone else just follows along. The talker is given a false sense of empowerment believing they have control. The wise leader will learn what it takes to motivate this individual and what it will take to bring the best out in the rest of the team.

Team building involves bringing out the best in each member. Some members can be timid allowing other members to make the decision and they’re along for the ride. The problem here is that there are a select few who are actually running the team rather than having involvement from all. If all are not participating it makes it tough to get strong commitment for all because decisions are being made that some might find objectionable. But because the team leader didn’t allow the opportunity for them to speak up, they go along half-heartedly accepting the direction the project is taking even though they might know a better course of action.

Changes are inevitable in a project, and the PM has to manage them effectively with a continual team-building efforts. The PM should continually monitor team functionality and performance to determine if any actions are needed to prevent or correct various team problems. With team building, as the PM develops the team, team performance should increase.

One model of team building involves five distinctly different stages of maturation in the team (Tuckman, 1965):

1.    Forming: This is when the team is getting to know each other. They’re interested in who each member of the team is and what they bring to the table. Questions like what do they know and will they be able to help me if I have a problem. Teammates also want to know that the other teammates will carry their weight.
2.    Storming is where the team begins to dig into the project goals and objectives. They begin to define and divide the tasks needed to be done and who will be responsible for completing those tasks as well as when. Technical decisions are made during this period. Gaining an understanding of the project processes also occurs. Cooperation can become counterproductive if the team does not collaborate well.
3.    Norming is the beginning of cooperation amongst the members of the team. They begin to trust one another, especially each others abilities.
4.    Performing is when the team begins to work as a well-oiled machine. Trust is attained and production increases. Conflict is minimal but productive as they work through issues easily.
5.    Adjourning brings the project to a close. The final product is approved for production and the team moves on to the next project.

Team building can be additionally enriched by gaining top management support; encouraging team member commitment to the goals and objectives of the project; introducing appropriate rewards, recognition, and ethics; creating a team identity; managing conflicts effectively; promoting trust and open communication among team members; and providing leadership. While team building is essential during the front end of a project, it is an ongoing process. Changes in a project environment are inevitable. Maintaining ownership and buy-in form the team will be difficult. To manage these changes effectively, a continued or renewed team-building effort is required. Outcomes of team building include mutual trust, high quality of information exchange, better decision making, and effective project management.

Three Spaces of Projects

As discussed above, part of team building involves creating the right environment in which to work. The dynamics of a project have been said to operate at three different spaces of project management. Space refers to an abstract boundary of human relationships.

First, people interact within the systems occurring in an expansive organizational space. This is the space that is defined by the organization that all members of the organization have to abide by. These include where in the building a team member’s desk is located; dress codes; hours of operation; company vision and goals.

Next, people interact with each other within a smaller space known as a team space. Because each project is different, organizations allow them to set up their own rules and processes so long as they fit within the organization space. The team space is defined by the team. This is where the team defines how members will interact with each other. Rules are defined as to how communications will be handles, how members will conduct themselves in meetings, how status reports will be delivered.

The last space is made up of each team member’s personal space where the individual team member’s interactive thinking occurs and human factors are formed. This is the individual team member’s space to do with as they choose. They make up the rules and decide the direction they will go. From this space team members choose how they will interact with others on a day-to-day basis; even from one issue to another. Much of how we react is determined by how and where we were raised, what cultural beliefs values are, and our individual personalities. This is the space that the PM must learn as much as they can about the individual team member in order to effectively manage them. From this space the PM can learn what it takes to motivate the team member thus allowing the manager to better direct them so that it meets that motivational factor (Wong, 2007)

Motivation

Project team members come from diverse backgrounds. Each has their own expectations, and individual objectives that they want to meet. The overall success of the project depends upon the project team’s commitment.  This commitment is directly related to their level of motivation. Motivating your team in a project involves creating an environment to enable your team to meet project objectives while also enabling them to meet their objectives and what they value most. These values will likely include job satisfaction, challenging work, a sense of accomplishment, achievement and growth, perhaps even money.
The PM has to determine how best to meet the need of each team member by learning what does motivate each of them. One way to do this is by listening every day to how they respond to different interactions. Meeting with each team member individually will be time consuming in the beginning, but will prove to beneficial later in the project when you get to crunch time. By learning early on what it takes to motivate that team member the leader will be able to know how to ask them to step up to the plate when it becomes necessary (Spreitzer & Quinn, 2001).

One motivation tool to use is letting your team do their own communicating with stakeholders, so long as they can do so reliably. What this does is to build confidence in the team member that you as the leader believe in their ability to do their job. If the PM is constantly hovering over the team member, especially in meetings with business Subject Matter Experts (SME), interrupting and over explaining, it brings a level of distrust in to the relationship. The PM has to allow for the team member to rise or fall on their own. Setting the expectation that the team member has to work with the SME’s raising the level of confidence in the team member. More importantly; it takes a load of work off of the PM by letting the team do their jobs.

Communication

Today, business is changing faster than ever, and most of those changes are being implemented through projects that require even stronger project management. However, just using sound project management methods does not ensure success, as many a PM has learned. Many PM’s have learned that while their project is a technical success; everything works as the business requirements document, the functional requirements documents, and the technical drawings stated; but the project is deemed a failure because it didn’t meet the business objectives of the company (Campbell, 2009).

The biggest reason a project fails was because communication, identified as one of the single biggest reasons for project success or failure, failed. Real communication is essential not only within the project team, but between the PM, team members, and all external stakeholders. Open communication is the opening to building team, creating teamwork and getting high performance from team members as well as your stakeholders. Communications helps build relationships among project team members which helps to create mutual trust. Building trustful relationships helps to move the project along enabling it to meet the goals and objectives all have agreed to. The PM needs to be aware of the communication styles of all involved in the project; He needs to know the cultural nuances/ norms, relationships, personalities, and the overall context of the situation in order to communicate effectively. Awareness of these factors leads to mutual understanding and thus to effective communication. Identifying various channels of communications helps the PM to better understand what information they need to provide, what information they need to receive, and the interpersonal skills that will help them communicate successfully with various project stakeholders.

Stakeholder satisfaction can be met through a clearly defined project scope. In the scope the object and the goals of the project need to be clearly defined to meet the expectations of the business and the stakeholders. Ultimately they are the ones who approve the scope of the project. The PM needs to ensure that the scope defines how the object of the project will be met. He needs to ask and get answered the question of what is the purpose of the project: What need or problem is the project supposed to fulfil or solve? What business outcome is the end result?

The definition of the scope is the first means by which the team begins to make the connection between the stated business goal and the means by which to achieve that goal. One of the tools that incorporate the scope is the project plan, including the Work Breakdown Structure (WBS). In the WBS the project team defines the work needed to achieve the business goal. It breaks the work down into manageable work packages, sometimes referred to as activities. The duration of time it takes to perform these work packages is estimated which ultimately helps to formulate our budget. The stakeholders will have to review and approve the WBS, the budget, and the schedule that gets produced. All this activity brings a greater understanding of the strategic business goal of the project.

With the Communication plan the project determines what types of communication would be required including status reports, Business Requirements documents, Functional Requirement documents, Project Plan, Project Schedule, Financial Communications, and as you can see, the forms and types of communication are many (Westland, 2006).

Many of these types of communication were determined by utilizing other documents such as the Stakeholder Register, the Charter and Scope, as well as the project management plan.

Projects can develop what is commonly known as a Project Management Plan (PMP). The PMP helps put all the relevant structure under one document; it helps us to define how we were going to communicate; manage certain events in the project such as change management, and risks: Verzuh points out that the Change Management Plan should be tailored to fit your specific function (Verzuh, 2009). And he’s right because it is not one size fits all in Project Management.

PM’s should carry out team building activities to help determine and understand team member styles of communication such as by email, phone, types of reports, texting; this allows managers to plan their communications with understanding towards relationships and cultural differences. Listening is always an important part of communication. Both active and passive listening techniques give the user awareness of problem areas, management strategies for conflict and negotiations, decision making, and problem resolution.

What happens if you ignore project communications? You do so at your own risk. As stated earlier, many projects fail due to poor communications. Poor communications could be the result of weak leadership. Not wanting to be the bearer of bad news you will hope the issue goes away. Of course it never does go away. The issue just becomes worse until when you finally decide you need to tell upper management, it’s too late to solve the issue except at tremendous cost of time and money. You, as the PM, look bad because it’s your job to raise these issues so that can be solved; obviously the earlier the better. Part of your job is to solve these problems. Being the bearer of bad news comes with the job. The PM cannot be afraid to raise the red flag when a management decision is the only way to resolve the issue.

One area of communication the PM should consider is with the key roles of members of the project. Would your Business Systems Analyst be able to connect with business stakeholders? Can the Tech Lead deal with outside vendors in communicating technical requirements? Good salespeople learn early on that they can land a sale if they bring in a Subject Matter Expert (SME) to talk with the customer. It’s not like the sales person, or PM, doesn’t have the technical know-how; it’s that the business stakeholder, or customer, will have a tendency to believe the SME over the PM or sales person. The PM has to realize that if what it takes is the SME talking with the stakeholder to get the issue resolved, so be it. True leadership never lets their ego get in the way.

Political and cultural awareness

Politics are inevitable in projects due to the variety of backgrounds, and expectations of the people involved with a project. Skillful use of politics and power helps the PM to bring the project to a successful end. Ignoring or avoiding project politics and incorrect use of power can mean trouble in managing projects. Because PM’s operate globally in many projects, and many projects operate with a mix of cultures they are expected to be to handle a multitude of different situations. By being appreciative and make the most of cultural differences, the PM is more likely to create an atmosphere of mutual trust and a highly performing atmosphere. Cultural differences are not just individual; they can be corporate in nature and may involve internal and external stakeholders. One way to manage cultural variety is getting to know the various team members and developing good communication plan goes a long way towards reaching that goal. Culture behavioral includes those behaviors and expectations that occur outside of geography, ethnicity, or language differences. Culture can either slow or increase the speed of working, decision-making process, and the urge to act without appropriate planning or permission. Conflict and stress can occur in some organizations as a result of these differences unless addressed appropriately (Kerzner, 2001).

Politics, handled effectively, can help smooth the road in a project. Depending on the level in the hierarchy your sponsor has can be the difference between moving forward with the tools and the authority needed or finding brick walls in front of you. Having a sponsor of equal footing within the hierarchy of the organization with other department managers makes bringing in the big gun easier if needed. Having upper management support certainly helps to remove a lot of political obstacles as it gives greater authority to the PM. If the CEO of the company is supporting your project everyone in the company knows it and will usually bend over backwards to ensure you get what you need to reach the project goal.

Negotiation

Negotiation is a strategy of consulting with various parties of shared interests with a view toward reaching an agreement. Negotiation is an important part of project management and if done well, increases the chances of project success. The following skills and behaviors are useful in negotiating successfully: Analyzing the situation, and differentiating wants and needs. By focusing on the interests and issues rather than on positions you stand a chance of concluding successful negotiations. Be realistic when negotiating: ask high and offer low. When conceding, make it sound like a really valuable concession, don’t just hand it to them. The negotiations should always be a win-win proposition (Katz, 2009).

Influencing

Influencing is a method of distributing power by relying on your interpersonal skills to get others to move towards common goals. The PM should always lead by example, and follow through with commitments. Do what you promise to do, always. Clarify how decisions will be made in the project or when considering an issue or conflict. Use a flexible interpersonal style and adjust the style to the audience. Apply your power skillfully and cautiously. Think of long-term collaboration or effects on the project.

Decision Making Styles

There are four basic decision styles normally used by PM’s: command, consultation, consensus, and coin flip (random). There are four major factors that affect the decision style: time constraints, trust, quality, and acceptance. PM’s may make decisions individually, or they may involve the project team in the decision-making process. PM’s and project teams use a decision-making model or process such as the six-phase decision model (PMBOK, 2013):

•    Problem Definition; Fully explore, clarify, and define the problem.
•    Problem Solution Generation: Prolong the new idea-generating process by brainstorming multiple solutions and discouraging premature decisions.
•    Ideas to Action: Define evaluation criteria, rate pros and cons of alternatives, select best solution.
•    Solution Action Planning: Involve key participants to gain acceptance and commitment to making the solution work.
•    Solution Evaluation Planning: Perform post-implementation analysis, evaluation, and lessons learned.
•    Evaluation of the Outcome and Process: Evaluate how well the problem was solved or project goals were achieved (extension of previous phase).

Trust

The ability to build trust across the project team and other key stakeholders is a critical component in team leadership. Trust is connected to cooperation, information sharing, and problem resolution. Without trust it is near impossible to establish the positive relationships necessary between the various stakeholders engaged in the project. When trust is compromised, relationships deteriorate, people disengage, and collaboration becomes near impossible. Some actions PM’s can take to help build trust (Verzuh, 2012):

1.    Engage in open and direct communications to resolve problems.
2.    Keep all stakeholders informed, especially when fulfilling commitments is at risk.
3.    Spend time directly engaged with the team asking non-assumptive questions to gain a better understanding of the situations affecting the team.
4.    Be direct and explicit about what you need or expect.
5.    Do not withhold information out of a fear of being wrong, be willing to share information admitting you may be wrong.
6.    Be open to innovation and address any issues or concerns in an upfront manner.
7.    Look beyond your own interests.
8.    Demonstrate a true concern for others and avoid engaging in non-productive pursuits detrimental to the project or others.

Conflict

Conflict is inevitable in a project environment. Incongruent requirements, competition for resources, breakdowns in communications, and many other factors could become sources of conflict. Within a project’s environment, conflict may yield dysfunctional outcomes. However, if actively managed, conflicts can actually help the team arrive at a better solution. The PM must be able to identify the causes for conflict and then actively manage the conflict thus minimizing potential negative impacts. The project team is then able to deliver better solutions and increase the probability of project success. PM’s have to develop the skills and experience necessary to effectively manage to the situation. Managing conflict in a projects involves building trust with all involved parties early in the project; being open and honest, and to seek a positive resolution to the situation causing the conflict. PM’s make every effort to establish a collaborative approach among the team members to achieve full resolution of the problems. When the collaborative approach isn’t working, the PM must then use other methods for handling the conflict; forcefulness, accommodation, avoidance, or compromise. Managing conflict is one of the biggest challenges a PM must deal with on a regular basis. It requires use of all the other interpersonal skills of a PM in order to bring the conflict to a successful conclusion (Kerzner, 2001).

Coaching

Coaching helps propel the project team to higher levels of adeptness and performance. Coaching is about helping people realize their abilities through enablement and growth. It aids team members in enhancing their skills that could lead to project success. Coaching can take many forms and styles. In many instances, informal training is used to increase technical skills. Most companies expect that a minimal amount of coaching should be used since they think they’re buying the expertise already. Most coaching happens in one-on-one situations of the moment and the PM needs to know when to apply it.

Conclusion

The PM must reach deep into their experiences and training in order to effectively lead. PM’s are very unique people, but they’re not born leaders; they have to learn and experience it in order to practice it effectively. They’re expected to bring the project to a successful conclusion while meeting the needs of the business. They’re expected to bring the project to a successful conclusion on time and within budget. As stated earlier, the expectation levels are pretty high and the pressure can be extreme. It takes a special kind of leader to bring together an idea and make it all work together. PM’s are the boss of no one; yet are expected to get people to do what needs to be done and are held responsible if they don’t succeed. They have to bring together a group of people who have likely never worked together before and make it so they are a well-oiled machine working together. Depending on the size and nature of the project, that could be a lot to ask of any one individual. But by putting the right person with the right project one can expect that it will end successfully. That person needs to have experience in many different facets of people and technical know-how as well as a healthy amount of business acumen. Without these the PM as a leader will likely fail. With them, they can go far.

References:

Campbell, G. M. (2009). Communications skills for project managers. New York: AMACOM.
Covey, S. R. (2004). The 7 Habits of highly effective people: The 8th habit. Chagrin Falls, OH: Findaway World.
Fleming, Q. W. (2003). Project procurement management: Contracting, subcontracting, teaming. Tustin, CA: FMC Press.
Hesselbein, F., & Johnston, R. (2002). On leading change: A leader to leader guide. San Francisco: Jossey-Bass.
Katz, R. L. (2009). Skills of an effective administrator. Boston, MA: Harvard Business Press.
Kerzner, H. (2001). Conflict Project Management: A systems approach to planning, scheduling and controlling. Hoboken, NJ: John Wiley & Sons, Inc.
Kerzner, H. (2001). Project management: A systems approach to planning, scheduling, and controlling. New York: John Wiley.
Kouzes, J. M., & Posner, B. Z. (1987). The leadership challenge: How to get extraordinary things done in organizations. San Francisco: Jossey-Bass.
Northouse, P. G. (2004). Leadership: Theory and practice. Thousand Oaks, CA: Sage
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Tichy, N. M., & Cohen, E. B. (1997). The leadership engine: How winning companies build leaders at every level. New York, NY: Harper Business.
Tuckman, B. W. (1965). Developmental sequence in small groups. Psychological Bulletin. doi:10.1037/h0022100
Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.
Westland, J. (2006). The project management life cycle: A complete step-by-step methodology for initiating, planning, executing and closing the project successfully. London: Kogan Page.
Wong, Z. (2007). Human factors in project management: Concepts, tools, and techniques for inspiring teamwork and motivation. San Francisco: Jossey-Bass.

Project Initiation: A Critical Look- A Review

The question has come up, probably countless times, of just how closely companies follow PMI’s PMBOK guidelines on initiation. Mark Mullaly responds that not many do. His belief; that objective, reasoned, analytical and rational thought processes in choosing projects that meet a business’s goals or fit its strategy were the furthest thing from the truth. Truth be known, Mullaly felt that while this was widely known and practiced, many Project Managers would rather ignore what they know to be a critical topic in the industry.

rich garling

Politics
Mullaly’s belief was that for many companies the decision to choose one project over another had little to do with any rational, reasoned, or analytical thought. The decision had more to do with politics, pure and simple. Someone within the company, with plenty of clout and power, decided they wanted their pet project done. While there are some companies that follow a formal analysis of the merits of a proposed project and how it fits into the scheme of things, there just aren’t that many. And those that do follow some formal process don’t do a really good job of it.

The Process
In Mullaly’s article he explains what the initiation process for all projects is supposed to be, it is where all projects start. Someone comes up with an idea. That idea is analyzed determining what is the scope of the idea, what will need to be done, how long it will take, and roughly what will be the cost. According to the PMBOK Guide, the initial scope is defined, initial finances are committed, business case is written, stakeholders are identified, the Project Manager is selected, the charter is written and when approved the project becomes official (PMI, 2013).

The Business Case
One of the key deliverables is the business case or project proposal (Verzuh, 2012), a document that Mullaly feels is inappropriate to use to justify accepting an idea as a project (Mullaly, 2011). He feels that the formal usage of a business case is to justify the project in purely financial terms. We use tools such as NPV (Net present value), DCF (Discounted Cash Flow), IRR (Internal Rate of Return) and ROI (Return on Investment). Basically, you are trying to put a dollar value on costs and benefits. He feels it is impossible to put a dollar figure on an intangible such as security. Mullaly felt that any financial number measuring benefits, in a business case, is an estimation based upon an approximation derived from an inference; basically, we used the swag method or just simply guessed (Mullaly, 2011).

Communicating
So Mullaly suggests the best way to deal with hazarding a guess as to the cost of and the benefits derived from a proposed idea is through communicating. He feels we need to be open and honest about the kind of project we’re doing. We need to be open and honest about whether or not the financial projections justify moving forward with the project. The assumptions being made to create the financial projections need to be clearly defined and every one of the stakeholders needs to agree to those assumptions. All this effort is just asking whether a project is adequately worthwhile to examine further.

Business Strategy
As we have read in Verzuh’s book, initiation is highly important to business strategy. During this stage of the process the business should be deciding if an idea fits into the business strategy or meets the goals of this strategy. The business is supposed to justify the project because they have determined that it fits into the business strategy and meets its goals. The business further decides based on its ability to meet the cost and resource demands the project will put on the business. If it doesn’t, it should be denied (Verzuh, 2012).

But I have to agree with Mullaly, that while the optimal is to base the decisions to go/no go on whether the cost of the idea and the resources required bringing the idea to fruition are worth it to the company, many times I have seen where none of those criteria are used. There are times where an idea became a project, and then some other project that was approved by someone in upper management, which no one else knew anything about, started to pull resources and money from this project that had gone through the so-called approval process.

Initiation Process
While the process I described above is the optimal, it would be nice if we actually did it this way. I never seen it done that way at any of the companies I have worked for, although two have come close. Very few companies I have worked for actually have a process in place and those companies that do have a process usually follow a hybrid in-house system. Where I currently work we have a hybrid system. The initiation phase is called Demand Management. An idea form is submitted, a small committee of team managers review the idea form and then decide if the project merits assigning a project manager to it. The project manager is tasked with doing the initial requirements gathering from which an E0 Estimation is created and presented to the business requestor for approval.

Project Proposal
One of the problems I see is that the initiation process I described at my place of employment doesn’t take into consideration how well the idea fits into the business strategy or goals. In fact, nothing is ever mentioned. I honestly don’t think any of the managers know the company’s business strategies. Mullaly points out that one of the reasons why projects fail is because they simply don’t take the time to analyze and determine if the project fits the company strategy.

One document in particular, when properly used, can actually help to fully define the project so that an informed decision can be made. The project proposal contains the project goal, states the problem/ opportunity, offers a solution, details the costs/benefits of doing the project, shows how the project fits into the overall enterprise portfolio, defines the business requirements. It includes the scope, the risks, and a high level schedule. In a nutshell; it makes the business think the proposed project through to ensure that the business is choosing the project wisely.

In conclusion, what Mullaly and Verzuh both point out, that when used correctly, the process works. Mullaly just points out what is really common knowledge; many companies and organizations do not follow the process and the do so at their own risk. Part of a Project Managers job is to guide the team through the process and to help their company develop a process that allows them to make an informed choice that benefits the company and fits their strategic goals.

References:
Mullaly, M. (2011, March 1). ProjectManagement.com – A Critical Look at Project Initiation. Retrieved from http://www.projectmanagement.com/articles/262617/A-Critical-Look-at-Project-Initiation
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.

Feed Shark

Procurement Vendor Selection Criteria

Introduction
Many of the projects involved working with offshore contract developers. They provide Business Systems Analyst, Web Page Designers, Program Developers, Database Administers, and Project Managers. In order to select a vendor that would provide the quality work needed for the project, the sponsors and the project management, in conjunction with company procurement department, needed to develop evaluation criteria in which to measure information coming from the vendors. An Request for Proposal (RFP) would be issued to each of the vendors and from submitted RFP’s the selection committee would identify those vendors ranking highest in the criteria determined by the purchasing agent, and the selection committee to be relevant and material to properly evaluate a proposal (Fleming, 2003).

Project Description
The project was to develop a user form that would be used company wide by employees requesting access to various business systems used throughout the company. These users were located globally, the main project team was located in North Chicago, IL, and the business sponsors were located in Germany. The third party suppliers were located in both the United States and India. Documentation used in this process included the Project Management Plan, the Statement of Work and the project plan schedule (PMBOK, 2013).
Once the requirements were identified, and the solicitation package prepared, the criteria for selecting the responding vendors needed to be determined (Kerzner, 2001).

Selection Criteria
The following criteria would be used to select the vendor:

  • Criteria/Weight
  • SharePoint Experience / 30%
  • Resource Availability / 20%
  • Management Capabilities / 20%
  • Cost / 30%

Since the project consisted of developing an online SharePoint form it was considered highly important that the vendor have experience with developing in SharePoint, especially the latest versions. And since there was another project handling the upgrade to the newest version that would have a significant impact on our project it was very important that the vendor have experience with upgrading to the newest versions. The project was given a very tight timeline along with a tight budget; resources had to be available when needed according to schedule and within budget. This meant that managing those resources according to the project schedule would be a high risk and highly important (Kendrick, 2009).

The group also defined the relative value to be used to score each category:

Score Meaning:

4 – Fully satisfies
3 – Substantially satisfies
2 – Partly satisfies
1 – Does not satisfy

The group wanted to ensure that the meaning of each score was interpreted correctly. For example, if the criterion is “cost,” then a low cost would have a high satisfaction level. To calculate weighted scores for each criterion, multiply the weighting factor by the scoring factor. Total the weighted scores for each criterion to calculate the weighted score totals for each alternative.

While a number of criteria can be used; time, cost, expected management team of the project and previous performance history, were considered important to the project. As an example, assume that 100 points is the most that can be given to each of the criteria. The vendor that is selected would have the greatest number of total points. Weighing factors can also be applied to each of the four criteria. As an example, previous performance may be worth 200 points, thus giving 500 points as a maximum. Therefore, the lowest price supplier may be downgraded significantly because of past performance and not receive the contract (Kerzner, 2001).

SharePoint Experience Criterion
As noted above, experience with the SharePoint platform was a major requirement. The vendor also had to have resources that were highly experienced with the programming languages that make up SharePoint. These languages included C#, VB.Net, Java and SQL.

This experience with SharePoint required a further breakdown in the criteria used to select the vendor. The following ranking breakdown was created:

Qualifications of the vendor
a. Experience of proposed consultants
b. Availability of proposed consultants
c. Cost of each consultant
2. Experience with SharePoint
a. Versions
b. Number of years
c. Past performance
d. Experience with similar projects
e. Database experience

The following table would be used to record the criteria results for each vendor:

Vendor/Criteria SharePoint Experience Consultant Experience Consultant availability Consultant costs SP Versions Year’s experience Past performance Similar projects Database experience Resource Availability Management Capabilities Total Cost Totals
Vendor 1 4 2 3 4 2 2 2 4 4 2 2 4 35
Weighted Score 1.2 0.25 0.375 0.5 0.25 0.25 0.25 0.5 0.5 0.4 0.4 1.2 6.075
Vendor 2 4 2 3 4 2 2 4 1 3 2 2 4 33
Weighted Score 1.2 0.25 0.375 0.5 0.25 0.25 0.5 0.125 0.375 0.4 0.4 1.2 5.825
Vendor 3 4 2 3 4 3 1 3 2 2 2 2 4 32
Weighted Score 1.2 0.25 0.375 0.5 0.375 0.125 0.375 0.25 0.25 0.4 0.4 1.2 5.7
Vendor 4 3 1 3 2 2 2 2 4 4 2 2 4 31
Weighted Score 0.9 0.125 0.375 0.25 0.25 0.25 0.25 0.5 0.5 0.4 0.4 1.2 5.4

Conclusion:
As an alternative or in addition to the weighting systems, the selection committee decided to adopt decision rules. A decision rule tells the committee how to deal with a criterion under fluctuating conditions. For example, a decision rule might be: if management is rated anything less than satisfactory, the entire proposal is unacceptable, or, if the proposed price is thirty percent higher than the projects original estimate, it will be judged as being potentially unrealistic and the vendor’s proposal will be reevaluated to determine if there is a misunderstanding of the requirements. Thus the team was giving more meaning to the numbers making it easier to make a decision using the criteria being used to measure each vendor.
References:
Fleming, Q. W. (2003). Project procurement management: Contracting, subcontracting, teaming. Tustin, CA: FMC Press.
Kendrick, T. (2009). Identifying and managing project risk: Essential tools for failure-proofing your project. New York: AMACON.
Kerzner, H. (2001). Project management: A systems approach to planning, scheduling, and controlling. New York: John Wiley.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.

The Importance of Stakeholders

Stakeholders are vitally important in all projects. There will always be someone who has an interest in seeing a project succeed. In fact, no project gets started unless someone has an interest in it. Keep in mind that the main stakeholder, the sponsor, most likely came up with the idea for the project in the first place.

One thing is clear, you as the Project Manager, needs to identify all stakeholders in your project (Verzuh, 2011). Stakeholders are defined as those individuals or groups who are actively involved in the project or whose interest may be positively or negatively affected by the performance or completion of the project (PMBOK, 2013). And there can be many stakeholders and they can have an interest in the project in the most interesting or unusual ways. Stakeholders can also be both internal and external to the project.

Stakeholders have various levels of responsibility in a project. The sponsor is the main champion and also approves all expenditures. Your Program Manager oversees your project and numerous other projects similar to yours. The project team interest is in producing a quality result seeing it to completion. Customers/users interest is in wanting to use a product/service that will solve their problem or fulfil a need. As you can see, there are many different users and each of them has a different reason for being interested in the project.

Identifying these stakeholders can be challenging. Sometimes it’s easy to find them and other times you may get surprised that someone has influence over the outcome of your project. You have to ask the question of who is impacted by this project and in what way are they impacted? Does a stakeholder have approval powers over my project? If so, how, and what is the potential impact?

It is highly important to be very thorough in identifying these stakeholders. Miss one and it could cost you dearly. The three main ones are the sponsor, the resource manager and those with decision authority. I use a stakeholder register to store all information on a stakeholder. I look for such information as name, title, phone, email address, contact preferences, what is their role/interest in this project, what decision making responsibility do they have? And I ask each, or I find out what I can on the company systems, who is their boss?

I ask that last question due to past experience. I just recently inherited a high profile project that is showing signs of trouble. One of the first tasks I gave myself was to identify all the tasks, those responsible for those tasks and what did these tasks impact. I’m looking for all stakeholders, but first I have to understand what the project is all about so that I know where to look. I don’t want to be talking to the sales department if the project has nothing to do with sales.

After 2 weeks of identifying the tasks and the stakeholders we had a risk that became an issue. One of the functional groups that was supposed to supply a resource to perform certain tasks for us, and we had been assured they would do, suddenly told us they couldn’t do it. Two people from this functional group had actually approved these resources. The catch, their boss had the final decision authority and he wouldn’t give it claiming it was outside of their described duties. Lesson learned: always ask if the person you’re talking with has the final authority on making a decision.

So the key is to identify all the key players and stakeholders who have an interest in your project, learn why they have an interest, what their role will be in the project and keep a record of all information on these stakeholders. Word to the wise: don’t show it to any stakeholders, this is your information for your eyes only.

References:
A guide to the project management body of knowledge (PMBOK® guide) (5th ed.). (2013). Newtown Square, PA: Project Management Institute.

Verzuh, E. (2012). The fast forward MBA in project management (4th ed.). Hoboken, NJ: Wiley.

Three Spaces

It’s interesting how Zachary Wong, in his book Human factors in project management: Concepts, tools, and techniques for inspiring teamwork and motivation, felt that personal space is the most complex and least transparent of the three spaces (Wong, 2007). I have to agree wholeheartedly as my experiences show how putting a team together can be very challenging. It’s hard enough trying to pick the right mix together of onshore resources, especially if they’re of similar cultural upbringing and experiences; but try to create that mix from onshore resources of multiple cultures along with offshore mixed cultural resources. That is quite a handful of challenges.

I would consider the most important aspect of picking resources, besides making sure they have the technical knowledge and experience to complete the tasks, is are they of the right personality and temperament? Do their cultural beliefs and upbringing allow them to work effectively in the position being considered? As Wong suggested, everyday people are making judgment calls based on their beliefs and values (Wong, 2007).

I have had situations in which a fellow Project Manager had to determine when a task was going to be completed. This fellow Project Manager was a Junior Project Manager under my command. He needed to follow up with a Vice-President of the company to determine when he could reasonably expect approval of a document we need to move forward on a task. This Junior Project Manager was from India. In India they do not just go up or email, or leave a voice-message asking the question. They go about it in a roundabout way so as not to show disrespect, to show deference to authority. The problem here was that by the time he would get around to asking the question we would be behind schedule. Knowing this cultural difference meant my recognizing when to step in to cover a task while also showing respect to the Junior Project Manager so he wouldn’t lose face to his colleagues.

I will have to disagree with Wong on his feeling that some values are derived genetically (Wong, 2007). I believe that all values are learned or chosen by the way we’re raised. The only genetically passed on behaviors for humans are those dealing with survival. As Abraham Maslow described, people are motivated by five psychological levels of needs in which the most important one is physiological; basically the need to survive comes first placing cultural after this one is satisfied (Maslow, 1943). The balance of those needs: security, social, esteem, and self-actualization are all cultural, not genetics.

I have worked with many people from many different cultures. Many of these colleagues have successfully assimilated themselves into the American culture, their differences notwithstanding. It seems to me that if culture was genetic than these individuals would not be able to assimilate so easily. While there are differences in physical differences due to geographic location, and thus learned behavior due to those locations, our genetics is the same across the world. Our learned behaviors are only different due to location and society.

References

American Journal of Physical Anthropology. (1996). biological aspects of race. American Journal of Physical Anthropology, 101, 569-570. Retrieved from http://physanth.org/about/position-statements/biological-aspects-race/

Maslow, A.H. (1943). A theory of human motivation. Psychological Review 50 (4) 370–96. Retrieved from http://psychclassics.yorku.ca/Maslow/motivation.htm

Wong, Z. (2007). Human factors in project management: Concepts, tools, and techniques for inspiring teamwork and motivation. San Francisco: Jossey-Bass.

Contract PM

I live the changes that have come to the IT world in corporate America: I’m a contract consultant who goes where the demand is. What I mean by that is the market has changed over the last twenty years. It has gone from where employees could count on a job for life to where you’re hired on to perform a specific task within a given time frame. Once you have completed that task, you move on.

For instance, I work for a recruiting firm headquartered out of New Jersey. I’m assigned as a Project Manager to a major corporation in Deerfield, IL. The ratio of contract consultants to full-time employees is 75% – 25% and wants to change that ratio to 90% – 10%. Many companies today find it increasingly beneficial to hire contractors who specialize in what the company needs. MCI’s Dick Liebhaber pointed out that it is easier to buy scope than to recruit, train and mentor permanent employees (Fleming, 2003). Companies can instantly buy the brain power they need for the specific task at hand. The cost savings in training and benefits has to be enormous.

Global trends are also affecting how HR manages resources. The breadth of the available pool of talent opens tremendously when you have the world in which to look. Jeremy C. Bradley, in his article in the Houston Chronicle, notes how traditionally HR has been a somewhat isolated profession, but with globalization and mass communication the world is becoming a smaller place (Bradley, 2015). Training has to be a cross-cultural event; meetings are conducted using multi-technical tools like big screen television, WebEx and webinars. Many things have to be considered when putting a team together.

What is interesting, and it takes the opposite view, is a study conducted by the Society for Human Resource Management in which respondents stated that the three biggest challenges facing HR Professionals was retaining qualified help, developing the next generation of corporate leaders, and creating a corporate culture that attracts the best qualified employees (Society for Human Resource Management, 2012). It looks to be an interesting task considering that many companies, and MCI, are moving in exactly the opposite direction.

References:
Bradley, J. C. (2015). Global trends that will affect human resources. Houston Chronicle. Retrieved from http://smallbusiness.chron.com/global-trends-affect-human-resources-61643.html

Fleming, Q. W. (2003). Project procurement management: Contracting, subcontracting, teaming. Tustin, CA: FMC Press.

Society for Human Resource Management. (2012). Challenges facing hr over the next 10 years. Survey Findings.

Subramanian, V., & Ramachandran, R. (2010). McGraw-Hill’s PMP certification mathematics: project management professional exam preparation. New York, NY: McGraw-Hill.

Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.

Westland, J. (2006). The project management life cycle: A complete step-by-step methodology for initiating, planning, executing and closing the project successfully. London: Kogan Page.

Enterprise Project Management & Project Management Office

Enterprise project management (EPM) is the integration of procedures, technology, organizational structure, and people that ensures alignment of projects to company strategy and goals.

There are three tiers of management in the EPM model. These tiers form the relationship between project, the projects resources, and company strategy. Project management focuses on the effective deliverance of selected projects. Program management is really management of multiple projects and it serves to coordinate projects and the resources that each of these projects share— particularly the people. Usually these projects share a similar goal and processes. Project portfolio management, associates the selection of projects and programs to the strategic goals of the company.

Program management is the management of multiple similar projects by individual project managers for each project and one Program Manager overseeing the whole. It strives to remove the confusion inherent by many related projects by effectively deploying limited resources, particularly personnel, among each project. It is able to do this by tracking relationships among projects, and managing projects or tasks that add value across projects yet are burdensome to any one project.

Project portfolio management (PPM) ensures that projects and programs promote organizational strategies and goals. It tries to do all of that by managing the limited resources available within the company. It requires disciplined decisions driven by priorities established by the Project Management Office or Executive decision.

Project Portfolio Management (PPM) has three primary purposes: align project selection with strategy; assign limited resources based on priorities; optimize deployment of resources across projects.
The benefits of PPM include: balancing projects by risk and reward; focusing on meaningful results that support strategic goals; choosing the right projects with the right resources to complete them; using strategic priorities to direct resource allocation.

The roles in PPM provide the authority and knowledge for PPM to function. The following roles should be included as part of any PPM: Steering Committee provides the link to the enterprise’s strategy and operations to ensure that the portfolio adds value to the organization; Portfolio Experts provide the working knowledge of portfolio management; Project Sponsors provide the expertise on the business benefits; Business Analysts are the experts on conducting analysis and documentation that help in making the decisions concerning a project.

Project Management Office primary purpose is to provide and maintain the project management standards and promote their use in an organization. The PMO actively supports a variety of projects by management of the perfunctory chores such as building and updating the project plan and budget documentation used by the projects. A PMO will also supply project managers to projects all over the organization. And, because it provides the project managers to the projects, the PMO can enforce the project management standards it establishes.

At work there are numerous PMO’s, usually one for each division and one main corporate PMO. Each of them operates differently from their colleagues in other divisions. The ultimate goal is have the one main corporate PMO guiding all the divisional PMO’s. work has a long way to go to meet that goal.

References:
Fleming, Q. W., & Koppelman, J. M. (2010). Earned value project management. Newtown Square, PA: Project Management Institute.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.

More on Project Communications

At one of the companies I have worked one of the documents each project is required to submit to the PMO is the “Project Management Plan (PMP)”. The PMP provides a mechanism in which to centrally locate many of the projects individual management plans including the Communication Plan, the Risk/Issue Management Plan, the Cost Management Plan, Change Management Plan, and the Document Management Plan.  PMI says that managing communications includes the methods essential to guarantee timely and correct planning of information used to run the project. This includes the gathering, dissemination, managing, controlling, monitoring, and eventual storing of project documentation (Project Management Institute, 2012).

Now, it’s not the typical plan that one would think of, nor is it a project schedule. This documents objective is to describe the project management system the team is going use to manage the project. The most important part of this whole document is the Communication Plan.

PMI points out that there is a need to define, plan and manage communications (Project Management Institute, 2012). I’ve learned through the years of managing projects that communications is all important. If you don’t communicate with the stakeholders and your team what is going on at any given moment in your project, your project will likely fail.

With the Communication plan we determined what types of communication would be required including status reports, Business Requirements Document, Functional Requirement Documents, Project Plan, Project Schedule, Financial Communications, and as you can see, the forms and types of communication are many (Westland, 2006).

Many of these types of communication were determined by utilizing other documents such as the Stakeholder Register, the Charter and Scope, as well as the project management plan (Project Management Institute, 2012).

The PMP also help us to define how we were going to communicate certain events in the project such as change management: Verzuh points out that the Change Management Plan should be tailored to fit your specific function (Verzuh, 2009). And he’s right because it is not one size fits all in Project Management.

The PMP plan describes the roles and responsibilities of those able to request changes and those who approve the changes. Its plan describes when a Change Request is required:

  • Changes to the project’s scope / Business Requirements have been identified or requested.
  • Changes to the project’s budget have been identified or requested.
  • Changes to the project’s schedule have been identified or requested.

The plan requires that a Change Request Form be used to request a change and that it must be submitted to the Change Review Board for approval. In our case there is no maximum dollar limit, every change request no matter the cost has to be approved by the business sponsors.

The Project Manager has to be a communicator as well as a leader. They cannot be afraid to bring bad news to the forefront. Good news doesn’t always happen in projects. But the bad news could help in keeping the project from going from bad to worse. I would rather be accused of over communicating than to be accused of under communicating. When I over communicate I can always cut back. I under communicating once and I lost my job.

References:

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition.

Newtown Square, PA: Author.

Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ:

John Wiley & Sons.

Westland, J. (2006). The project management life cycle: A complete step-by-step methodology for initiating, planning, executing and closing the project

successfully. London: Kogan Page.