Incorporating JAD Sessions into the Planning Phase

I first became familiar with Joint Application Design (JAD) sessions when I worked as a consultant for an Internet service provider, and have encouraged its use ever since. JAD sessions originated with IBM in the late 70's and the principles have been applied in many organizations since. The fundamental element that I find useful is the interaction of the participants. Key JAD participants include:

• Facilitator - to be considered a true JAD session, it is important to have a facilitator to maintain the communication flow and to keep the session on track.
• Project Sponsor - the sponsor should be present in order to agree to decisions that are proposed during the session.
• Business Users - permitting a few of the actual end-users to attend helps to gain their perspective (if you can get their participation early on in the project, it will provide you with valuable insight as the project progresses and may show a disconnect between what the sponsor envisions and how the users actually would use the final product.)
• Project Manager - by evaluating the discussion, potential changes to scope may be identified as well as noting any potential risks or issues.
• Project team members - the most critical aspect is to ensure that the development team attends especially the leads, but also invite an architect and any members from other teams whose input is required to complete the project.
• Scribe - be sure to have someone who is not actively involved in the session to be the note taker so that their focus is on capturing important discussion items and recording all decisions that are made.

JAD sessions are beneficial because they get all the essential project participants together early in order to determine the basic design of the system. This seems like a logical approach, but many projects limit or even skip the design phase discussion and jump right into development. JAD sessions help to identify design components that may work more effectively when we have reviewed possible alternatives. Although participants may be reluctant to speak up and share ideas at first, the facilitator can elicit feedback and encourage more open discussion - even a debate over which direction is best for the project is actually healthy - better to debate early than to argue later.

A single JAD session may not resolve all issues. My tip is to schedule the first session for about two hours and if possible, do so as a breakfast or lunch meeting to help establish a positive and more relaxed atmosphere in which participants feel encouraged to speak up and share ideas. The follow up JAD session should provide a brief summary of open issues so as to refine the project requirements, determine the architectural approach, define formal deliverables, and provide schedule estimates for major milestones.

Trying this approach may be met with resistance as some stakeholders may not think JAD sessions are necessary, but the better the planning on any project, the better the end results (i.e., less cost over runs and more on-time delivery) can be expected.

PM and the Economy

In recent months, it seems that we hear about another company either going out of business or reducing its workforce, nearly every day. This seems staggering as more workers lose their jobs and companies attempt to remain solvent. But what relevance is project management to these recessionary conditions? How can project managers be of assistance to their organizations?

If you have not done so already, now is the time to introduce the concept of "portfolio project management" or PPM to your PMO and to senior management. PPM is a method for organizing projects or groups of projects into key categories which can be more easily managed. The idea is to find the right mix of projects that best maximize an organization or departments goals and objectives while making the best use of resources and rate of return. (The concept stems from the management of financial portfolios.) Each project is measured against its ability to meet the goals and objectives of the portfolio and those that are not successful may be reevaluated to determine if they should be dropped from the portfolio.

How might this approach be helpful to an organization, especially in tough economic times?

First, an organization must be able to react to the current conditions as well as be proactive and take measures that will help the company ride out the recession. This means that the goals and objectives that the company outlined five or even two years ago may no longer be applicable in the recession. By determining any changes that are needed to corporate goals and objectives, projects can be aligned with those efforts.

Second, if a project is on time and on budget but meets no new goals, is it really important to continue the project? Can it be shelved for a few months? Is it still vital to the company's mission, and if not can we close it? This can be really difficult to think that time and money has been spent to work on project that will be placed on hold or even killed, but if it will save jobs or help to bring in revenue to focus elsewhere, it might be worth it. For example, a new server replacement here and there may be critical to day-to-day operations, but is this really the best time to upgrade the entire network infrastructure?

Third, we've all worked on projects that really had little or no relationship to corporate efforts - the ones that are 'pet projects' to one of the senior managers and to whom you can't say no. With PPM, these types of projects have little hope of getting off the ground as they will be unable to meet the criteria for being included in one of the portfolios. With tough economic times, it is difficult to justify these types of projects and easier to decline them due to a shortage of resources for the company as a whole. The project selection process becomes more democratic.

Lastly, since projects are reviewed not as individual components, but as to their relationship within the portfolio, better control is achieved (i.e., not only is the status of a project important, but so is the overall health of the portfolio.) As each corporate goal and objective is evaluated each year, so are the portfolios and the projects therein - what is working versus what is not, which projects and portfolios are profitable and which are showing over-runs? These measures should be viewed quickly enough to determine which steps to take, even if that means eliminating a project or a portfolio. We are all ware that financial times are too difficult to wait to see if a project will overcome its losses and show some eventual success. As managers, we need earlier identification of issues for projects, portfolios, and even the recognition of troubled programs - this is key to eliminating waste and making better use of resources, before any further staff are cut or corporate losses become unfortunate but necessary.

Here are some useful links to sites that offer more information about PPM:

http://www.michaelgreer.com/ppm.htm
http://www.ibm.com/developerworks/rational/library/apr05/ciliberti/index.html
http://projectmanagement.ittoolbox.com/topics/ppm/
http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470126884.html
http://www.pmsolutions.com/uploads/pdfs/ppm_maturity_summary.pdf

Project Schedules

Not too long ago, I attended a meeting in which the discussion turned to the proposed schedule and a question was asked as to how we could ensure that IT would stay on track and meet the major milestones. Per my view, the issue was not whether the staff would make every attempt to meet our goals - within the expected time line - but whether the schedule itself was simply realistic and possible for the team to complete all development tasks as expected.

It is difficult sometimes to make the point to senior management that the careful planning, estimating, reviewing requirements, and risk evaluating all contribute to the creation of a sound schedule that is reasonable and can be actually be achieved. Too often, management targets a date and promises delivery without significant review with key stakeholders - at which point, the project manager is left scrambling to find sufficient resources to complete the necessary tasks - sometimes with little or no increase in staff or funds.

Schedules involve so much more than inputting dates into a scheduling program. Project schedules need, at a minimum, a work breakdown structure, careful review of the scope and specifications, and input from each member of the team. But, trying to explain dependencies or risk mitigation is met with blank stares or bored postures, not to mention activity duration estimates and resource calendars seem irrelevant - that is until you need to explain to executives that a project may need to be delayed or released in phases due to resource constraints or conflicting priorities.

Introducing a schedule management process is necessary. However, it needn't be a major overhaul; to your existing procedures since it is really part of the overall project management process. Senior management generally understands that in order to make process improvements and improve basic methods of accomplishing tasks, change is needed and will be very beneficial, but they may tend to forget that those same changes may also impact them and their goals as much as any of the business units. IT is not the only responsibility area in the organization when undertaking a software project. The business owners must be able to work together with IT and be viewed as partners, not as the folks on the next floor who keep making new requests that take even longer to complete making us appear to not meet our dates and reach schedule milestones.

That brings me to the topic of project change management - but that is to be saved for another post.

Managing Problem Teams

Managing a project is complex enough without adding team conflict issues into the mix. Managing a project team can certainly be a difficult undertaking, especially if the team members do not get along. So then how do we as Project Managers accomplish the task of getting the project completed and not having chaos during the execution of the project's key activities?

There are a couple of underlying questions to be addressed here:
1) are the members of the project team direct reports of the project manager or is this a matrixed team, and 2) has the project team been given clearly defined roles and responsibilities.

In the first instance, we must determine how much authority the Project Manager has - not only pertaining to the day-to-day running and managing of the project, but to what extent the Project Manager has the ability to define and enforce basic guidelines of behavior to project team members. If the project team directly reports to the Project manager, the lines of authority are usually more clearly defined. The project team is expected to work to accomplish the goals and objectives set forth by the project management plan as well as to generally abide the directives of the Project Manager. Most Project Managers have had an opportunity to become well acquainted with their direct reports and establish a positive relationship with each team member, as well as foster a cohesive and functioning team. If issues arise between team members, this line of authority is more easily managed in that the Project Manager has a history and strong relationship with the team to usually diffuse and resolve issues that may negatively impact the project.

If the Project Manager has few or no direct reports and the members of the project team are composed of staff from more than one group or division, then the project is a matrixed one. Team members may have prior negative experiences with one another or may develop misunderstandings while engaged on the current project that could lead to disruption on the current project. Without the same direct lines of authority, this situation can be more difficult to manage, but can be mitigated in terms of getting the team to perform in a more cooperative manner. For example, at least once a week, the project team must meet, preferably in person, but by teleconference if necessary. Each team member should be encouraged to provide not only status but to review issues and propose solutions. An "issues board" can be used to track items that are outstanding or new issues as well. each team member has the opportunity to propose ideas. In addition, it is important for the Project Manager to speak to the particular individuals to determine how to best resolve the issue. Sometimes, this may mean removing one or more person from the project or minimizing their role(s). If the team member is critical to the success of the project, it may become necessary to speak with the supervisor/manager of the team member and review the situation so as to alleviate the issues and continue the work.

In the second instance, team members must know what their role on the project is expected to be - any ambiguity may cause confusion and lead to difficulties among the team. A roles and responsibilities chart is often effective as is a list of duties that is to be shared. For example, if two developers are working on similar modules, who is expected to integrate them? How is the testing to be divided and who will perform code reviews? If clearly established policies for these tasks are not already defined, they must be designated and provided to the team at a very early stage so as to avoid confusion later in the project. Another example concerns team "leads" - if a team member is a lead on another project, he may assume he is to be the lead on this project as well or it may simply be taken for granted to be the case. However, this needs to be defined and agreed to by the key stakeholders as well as the designated lead who may already be overwhelmed with duties on many other projects. Include the roles and responsibilities in the project management plan as well as provide it as a separate document to the team.

Additionally, the importance of the project is necessary to be clarified and reiterated to the members of the project team. Management must support the project and continue to give staff a clear message that their contributions are not just necessary but greatly appreciated by the organization. It must be made clear early in the project that the Project Manager is the authority for the project and has been designated the point-person for the successful outcome.

A few suggestions at helping to facilitate (i.e., being a referee) for difficult projects:

• Conduct bi-weekly progress reviews (sometimes called 'sanity checks') to see where the project really is in the minds of the project team. This goes beyond what they write in their status reports but gets to the heart of issues on a regular basis
• Ask one person each week to kick off the meeting but don't let it be the same person each week - that way, the team members do not know who will be called upon each week and will be more likely to come prepared
• If possible, have team-building sessions, or perhaps brown-bag lunches in which key topics are discussed that are relevant to the project
• Monthly, have a short breakfast meeting to thank the team for their efforts and the work completed. As a Project Manager, it is important to keep the team motivated to accomplish the remaining work ahead.
• If the project seems to be headed in any direction that might cause delays, overages, or any inkling of potential failure speak to senior management immediately and voice your concerns.
• Invite a senior manager to attend a weekly status meeting, to speak at a brown-bag lunch, or for offering words of encouragement to the team when necessary.

The importance of the project must remain the focus and finding a way to address and resolve discord is essential to minimizing negative project impacts.

Project Planning

In watching the Inauguration today, I was so very proud and excited at seeing such an amazing historical event. Later, I was reminded at the enormity of all the planning necessary to be able to successfully accomplish this undertaking.

All projects need to consider the planning stage as important as the actual execution phase. This is certainly true for development projects. Many times, it is easy to receive an initial set of requirements and begin developing – the idea being that to get a head start on the project will save time later if issues arise. However, the opposite is often the case as more pieces of the requirements puzzle come to light and additional user needs are discovered that are more complex than originally anticipated.

Why then, is planning so undervalued? Perhaps because customers do not appreciate being charged for evaluations, surveys, feasibility studies, or other pre-development assessment activities. Instead, they’d rather see their investment in action and have a new system underway as quickly as possible. But, if we are to provide them with a truly valuable service, we need to ensure that we take as much into consideration as possible – the unplanned variables of any project are sure to occur, but these can be minimized if we outline important items including not only the scope, but also a project management plan that includes an overview of the proposed timeline, deliverables, staff, risks, and a strategy to be used to communicate throughout the project.

The saying “failing to plan is planning to fail” certainly applies to managing projects. The time invested to planning is wisely spent and will pay off greatly as the project unfolds. Devoting the energy of the project team (and stakeholders) to planning brings about more questions, but having those answered early makes for a much clearer picture of what the project is to look like, hopefully more like a well-orchestrated event as the historical one seen today.

Project Communication

As most project managers will tell you, the essential element of project management is communication. Beyond the schedules, budgets, WBS creation, and finding the best resources for your project, nothing can sink a project like poor communication.

Communication is not simply relevant to the members of the project team, but also critical to the key stakeholders and sponsor too. How often have you noticed that a discussion that was held this morning has morphed into something that was either taken out of context or is based on something that was never actually discussed.

As project managers, it is important to ensure that we act as the point of contact for all formal communication and that we take the initiative to speak to the primary stakeholders, preferably in person or at least via telephone or video on a regular basis - which should be weekly at a minimum.

This means that the PM has on-going meetings with members of the project team and with the stakeholders, and that the PM is the first, rather than the last, to know when an issue arises and has already begun to propose solutions and prepare to reslove the issues.