Updated Your Work Break Down Charts (WBS)

There are changes you can make to your WBS charts, you can change them to an indented chart because the format is preferred over the flow format (below post) when your project is large. Also, if you are contracting or work for a government agencies they require the indented format WBS when a Request for Proposal (RFP) is submitted to bid on a project. These charts come in handy for a multitude of job descriptions, quality assurance, business analyst, project managers, business owners and always uncover areas that might have been missed during the planning and or analysis phase of the software development lifecycle. (SDLC) Even though the WBS is widely known as the primary tool used to scope a project, I have seen it used successfully in requirements gathering and analysis, quality assurance, design and development, implementation and training.

Keys to maximizing your WBS:
1. Assigning responsibility.
Once you identify all the elements of a WBS, it is very straightforward to determ…


Motivation has an importance relationship to delegation because without it, delegated task are not performed.

To delegate effectively to project team members, try some of these ideas:
1.Determine desired results.
Make sure to develop a plan and create objectives. Many managers determine desired results, but do not communicate them clearly.
2.Assign and discuss tasks.
Assignment usually takes place but not discussion. Provide team members with an opportunity to ask questions and clarify instructions. This is the most important ingredient for successful delegation.
3.Delegate authority.
Make sure your team members and the rest of your organization know what tasks are delegated. There can be no confusion if authority to act exists and knowledge of which tasks have been delegated has been imparted.
4.Communicate expectations.
This step is not done very well. "Just do it" or "just handle it" are all-too-common requests from project managers. Make sure that your expectatio…

Organizational Concepts

Review these four concepts that relate to ability and right to act. Use these principles to help project team members contribute to your projects and to make the right types of decisions.

Authority relates to the vertical hierarchy of positions in organizations. It is defined as the right to act. Authority consists of making decisions within a designated scope, assigning tasks, and expecting satisfactory performance of tasks. Examples are directing others and authorizing the spending of funds.
You must delegate authority to enable others to act.
Responsibility is defined as an obligation to act. Unlike authority, responsibility (once accepted) cannot be delegated. Responsibility typically begins when an individual accepts a position at an organization.
Accountability uses elements of authority and responsibility. It is defined as being liable for actions. Once you accept a delegated assignment, you have accountability to act and to answe…

Organizational Structure

Think of an organization chart as a road map, it is more like an abstraction of a dynamic condition. An organization chart is limited in scope because it does not identify the companies’ intangibles like, skill sets, personality, attitudes and experience.

Organization charts help to define company relationships and usually answer some standard questions.

What is my position in the organization?
What is my title and job description?
Who am I accountable?
Who is accountable to me?
Who are other people of interest in the organization?
What do these people do?
What are the reporting relationships for these people?

If you do not address these questions, you will not understand important organizational relationships. If you act without organizational knowledge during your project you might violate company protocol(s). If you work or are in charge (PM/Scrummaster) of projects it is most likely that you use a matrix organization. The roadblock to this type of organization (matrix) is t…

Overcoming Resistance to Change

Here a few of my ideas that you can use to overcome resistance to change:

1.Involve those affected by a change in planning and implementing the change.
If you are using an agile frameworkEVERYONE has to be involved from day one, if you are using a more traditional framework you can make sure that your team members support change because you have to include them. People are less adverse to change when they help to create and get involved in planning and implementation, you will always create a more involved, positive and stable team. Advise all the team members that while their input may not be incorporated into a planned change, you will value, note their contribution and will consider it if it positive for the development of the application.

2.Thoroughly explain the need for the change.
When you explain a proposed change to a team member, you may discover that a change is not needed. Agile frameworks force the team to have face to face open communications and daily stand-ups so you w…

Change Management and Empowerment of Teams

We all know there are two types of people in this world: those that like change, welcome it, embrace it, and thrive on it and those that are secure with the status quo, keeping their heads down and hoping things remain the same. For many individuals the ability to thrive on change is a quality for many people, they also love stimulation and the excitement of learning new things. There is also a larger group of individuals who when they encounter new experiences before they are ready for them, these groups prefer change later.

For Project Managers change has two basic dimensions:
Change that each project team member must individually address.
Change that all team members must make to support your project.

When change impacts you or your team members, you must understand its nature to use change to your advantage. Most of the time predictability for most projects is low, consequently, it is necessary for each team member to become very comfortable with change to learn it love it and liv…

Team Development Stages

There are a number of different models that describe the stages of team development. In my experience I have been exposed to agile frameworks and waterfall frameworks in the development of applications. I traditional model of team development transcends the framework the team is utilizing to build the application. Traditionally team development has 4 main stages and the differences between the frameworks used are not that significant.

Try to focus on the models of team development they are very basic concepts I have used in the past:

When team members are assembled in their team for the first time, they experience many different feelings. Some are enthusiastic and optimistic, while others may be more cautious. I have never in this stage seen team members display outright anger or resentment. Sometimes they question the validity of the project, but they are careful because the level of trust and commitment is typically low.
Opposition will happen on all p…