best practices Archives

Tag Archive for: best practices

When you hear the word “workflow” do you get excited, like you can’t wait to spend a day in front of a white board with a cross-departmental team and map out how you will all work together happily ever after?

Or, are you like most people and dread the thought of going through the process of designing and implementing a new workflow, no matter how badly you know your organization needs to change the way it works?

Anyone who’s been through an organizational change in how teams are to work together already knows this process is never easy. Just thinking about this may trigger thoughts of:

Heavy, unmaintainable process that doesn’t scale
Wasted time going around in circles trying to get buy-in from everyone involved
Rigid rules that lead to impersonal interactions
And maybe some overwhelming diagrams or documentation just to add salt to the wound

When the Product and Engineering teams here at Jama set out to establish a workflow between our two groups we had some of the same concerns. We were already productive, but we were growing quickly (and still are!) and we knew we needed to establish a formal way of communicating, one that would scale over time.

What makes a good workflow?

So the first question we had to answer for ourselves was, “What makes a good workflow?”

Simply put, the intent of any workflow is to help people better work together.

But people aren’t simple. And moreover, the products they produce aren’t simple, either. As a society we now rely on critical software and technology to run our economy, our military and to save lives. These products are, by definition, complex.

So as we developed our workflow at Jama we focused on the aspects that we knew would make us not only work faster, but better. Our Engineering and Product teams were already committed to Agile practices for its focus on people first, and even have an in-house coach. What we needed to improve was our communication to the Business, and also aligning all three groups around common goals—the “why” of what we’re building. So we decided to document and formalize our commitment to Agile by designing a workflow around these tenets:

Facilitate fluid communications without a heavy-handed process
Enable quick and confident decision-making

Getting Down to the Science (Behavioral Science, that is)

But we didn’t stop there. With my educational background in neuroscience and human behavior, I knew that groups can agree to a new workflow on paper and still fail to maintain it, especially in growth periods, which we were (and are!) definitely in.

We’d need something more than a beautiful flow chart. We needed to know what makes teams adopt new ways of working and stick with them.

I started investigating some of the latest research in how people work in teams and how they adapt to change. I found some gems that applied to workflows, as well as other struggles in my life, because really, what part of life isn’t about dealing with people and adapting to change?

There were two theories that I found particularly applicable to our team:

Status Quo Bias
Choice Overload

According to The Behavioral Economics Guide 2014, Status Quo Bias refers to the fact that “…people feel greater regret for bad outcomes that result from new actions taken than for bad consequences that are the consequence of inaction.”

People don’t like change. Not surprising. But what this research also says is that people are especially averse to change in work processes, even if what they’re currently doing isn’t working, because they’re worried that if the change leads to failure they’ll be liable and life will be worse than it is today.

Also, people will say that they like choices, but if they’re presented with too many options they become confused and overwhelmed and get choice overload. They need to have the right amount of information, at the right time, so they can evaluate and make a decision on a purposefully limited amount of criteria with just the right amount of, and right type, of data.

The Agile Workflow Design

Like I said above, a good workflow supports the people within it and improves their working relationships. So the first thing we did was get clear on who are the people who make up product development teams, what are they each responsible for in the process, and how can we support their communication with each other.

click to enlarge

This chart illustrates an example team, across departments, and the people who need to weigh in on strategy, plans and key decisions, and at what point in the product development cycle. This is a good, if simplified, representation of what our customers tell us about their teams’ compositions and dynamics, and also how we work at Jama.

click to enlarge

And this–finally!–is the Agile Workflow Design. If you’re familiar with Agile, you’ll recognize many of the steps. This chart also shows which tool holds which types of data, in our case, Jama and JIRA, indicated in the lower left corner.

Next, I’ll zoom in on the key steps in the Agile Workflow Design. The diagrams below don’t look exactly like the one above, and are designed to illustrate key points in the Workflow.

click to enlarge

Here the Product Manager or Product Owner documents the business need, or why we’re building this feature and who will use it and the value they’ll get out of it. This information is documented in Jama, indicated by the orange text.

click to enlarge

The Product Manager or Owner collaborates with Engineering—in this case, the Lead Developer—to understand the business need and develop Epics. You’ll notice two new things in this diagram. The first is the progress bar above the “Business Need” box, which indicates progress to completion. Right now we haven’t started development so it’s at “0%.” The second thing is the blue “Connected Users” icon. Right now there are 3 people involved in this project. Both of these indicators are taken directly from the Jama interface, where you can see current progress and the individual team members involved in a project, which is really useful especially if you have a global, distributed team, or, in our case, a growing company where you may not yet know everyone’s name!

click to enlarge

Now development work has begun. Epics have been broken down into stories in Jama, and that data has been synced, in this case, to JIRA (indicated in the blue text). Progress is tracked in JIRA and that data is synced with Jama. As indicated by the progress bar, we are now 15% complete in this work, and with the introduction of the developers, we now have 5 Connected Users.

click to enlarge

The QA team has been testing all along the way, but as we get closer to complete it’s a great time to confirm we’re still on track. We’re logging defects in Jama and syncing the status back to JIRA. We now have 15 Connected Users and we’re 65% complete in this work.

click to enlarge

Testing is complete and we’ve confirmed that this feature meets the business need. We’re now at 100% and ready for release!

And that’s the Agile Workflow Design, explained. Of course, for our team at Jama coming to this design was a gradual process, which included many conversations and agreements made. We’re always improving it and it’s been worth the effort. Now our teams are more connected to the business need behind our development plans, and other departments, such as Operations and Marketing have more insight into what we’re building, making it easier for those teams to do their jobs well.

Take This To Your Team

I want to leave you with a few useful things to guide you the next time you find yourself in a process meeting, or designing a workflow:

Workflows should connect people first, and data second. After all, it’s people who actually get the work done. It doesn’t mean that codifying a series of steps and procedures is a bad idea, as many people are building very complex things and they may just need to account for twenty well-defined steps in order to get a quality product out the door. What I’m highlighting is the fact that at every touch point where people need to exchange information there’s an opportunity to make that interaction as smooth and productive as possible. When you focus on this you’ll have an easier time getting the group working together in a “flow” as much as possible.

Remember the “why” of what you’re building. Stay connected to your original business goals, and build in opportunities to adapt to change as it inevitably arises. Don’t wait for people to protest since Status Quo bias inhibits that.

Avoid Choice Overload by limiting the number of available options when a decision must be made.

Hear more about team collaboration in the recently recorded version of our Agile Workflow Design Webinar. We cover these concepts and more, in-depth, and answer questions from the webinar audience.

About the author:

Robin Calhoun is a product manager for Jama Software, as well as a certified ScrumMaster. Calhoun users her education in human behavior and economics to direct product decisions and team management, combing this expertise with the ever-evolving body of knowledge in Agile development practices. Before joining the Jama team Calhoun was a product manager at Tendril, defining data-driven Energy Service Management products. She holds a degree from Columbia University in Neuroscience and Behavior.

Stop chasing down documents in DOORS and focus on the items within them that matter.

For many years, IBM’s Rational DOORS (v.9) has been a widely adopted Requirements Management (RM) tool for teams working with high-compliance systems engineering programs. Because it’s often sold into the enterprise as part of a larger IBM suite, its widespread use is sometimes a matter of default rather than choice.

If you’re like most of today’s systems-driven engineering organizations, you’re primarily in the business of producing complex, ﬁnished products and components, often involving a mix of hardware, software and ﬁrmware. You’re probably also in a hybrid-Agile development environment and figuring out how to scale that effectively.

In business, times change because needs change. Changes driven by the rise in software-driven products, the imperatives of on-time delivery, and extended supply-chain systems threaten to disrupt traditional, legacy manufacturing and engineering processes. Your teams are pressured to accelerate product delivery and manage growing complexity in distributed organization and supply chains, within products, and across a network of interrelated and interdependent products.

Jama is built to serve and evolve with the ways systems engineering teams build products. How is it different? Jama deconstructs documents into actionable items. You can easily see, grab and reuse items, and be confident that they’re current and include all related comments and status. Forget about wordy “reading assignments.” You can share specific work components with your team for review and approval, without the risk of compromising security or access permissions that document shuffling causes. And when it’s time to pull it all together again to submit or archive a controlled document version, Jama can do that, too.

Skeptical? Make us prove it to you. Sign up for a free 30-day trial and give us a shot. No installation required.

In this age of continuous delivery when increased time pressures compound communication breakdowns, keeping teams aligned has never been more important. Methodologies such as Agile and DevOps address these issues, and they require evangelists — plus tools — to support these practices. Jama Product Manager Derwyn Harris weighs in on this piece in CA’s publication, rewrite, on “purposeful collaboration” and how social media conventions within product development software support these teams.

Smart collaboration is critical in any tech endeavor, because moving parts are plentiful. But what does “collaboration” really mean? It’s a spongy word. Are we talking instant-messaging group chats? Scrums? Standups and retrospectives? Brainstorming software?

As the application development process quickly evolves, so must the support system that surrounds it. That means new tools are required, along with new ways of thinking about working together. We asked DevOps pros for a blueprint to the brave new world of teamwork and idea sharing. (You may never get a group email blast again.)

Big Picture First

Ajay Kaul, managing partner of AgreeYa Solutions, starts with some simple truths. “It is very important to communicate effectively with the IT and delivery teams, explaining to them that the real goal is to accelerate time to market and deliver high-quality products,” he says. “The key is getting started with one project and later creating a team of specialists who can spread the DevOps gospel within the organization, whether you are a startup or a large enterprise.”

The essentials of well-designed DevOps collaboration begin before you undertake an initiative. Start with getting buy-in from upper management and addressing any gaps in your employees’ skills, knowledge and availability. “You need to build a competency within the organization,” Kaul says. “You need to select the right tools for automated testing, build-release integration, configuration, deployment, and network and server performance monitoring, among others.”

This early work requires investing time and money upfront, after you determine which tech tools you will need.

Who’s Driving?

You need a champion for this endeavor—typically, the CIO. The champion must create the collaborative environment needed for DevOps to succeed. It’s natural for CIOs to think of technology as an end in itself, but DevOps must be placed in the broader framework of overall business operations. “Instead of thinking how IT can change the world,” says Kaul, “one should think of how business situations inform the changes in IT systems.”

That sets up the CIO in a role as a planner and a manager, not just the technician in chief. CIOs must shift their thinking from focusing only on individual department needs to integrating cross-functional and interdepartmental collaborative teams, Kaul advises. While the CIO plots direction, team members promote the adoption of DevOps on a project-by-project basis. One person is driving the bus, but the passengers are active participants in arriving at the right spot. One key is creating DevOps champions throughout the organization to distribute the workload of DevOps evangelism and DevOps implementation. This approach creates a more natural, collaborative environment, because multiple leaders will be pursuing the strategy in different projects, teams and departments.

The Power of the Social Circle

The basic mechanics of collaboration are familiar to any business professional, particularly in the IT world, where feedback loops are essential for success. On a day-to-day basis, these mechanisms may be as simple as team members relying on messaging platforms to work together and solve problems quickly. Large-scale beta tests are useful when gauging how well a software implementation works. But as projects become faster and more complex and involve additional team members—as in a DevOps environment—such tools are insufficient for managing these workloads. That’s where “purposeful collaboration” comes into play. Purposeful collaboration uses the power of social systems to enhance more traditional tools like instant messaging, email, service desks and cloud-based content sharing.

“Purposeful collaboration uses familiar constructs like those in social media to connect all stakeholders related to the project, both inside and outside the organization, in a meaningful way,” says Derwyn Harris, co-founder of Jama Software, which markets its own collaboration framework. The key word here is “meaningful.” Many so-called collaborative efforts begin with the best of intentions but then devolve by throwing every piece of information at everyone involved. If you’ve ever been frustrated after receiving your 30th message in an endless mass email chain that you should never have been copied on in the first place, you know how aggravating this approach is.

Purposeful collaboration offers information in a more targeted way. For example, all team members may be allowed to comment on a design mockup, while only managers have access to functional requirement documents. Users can then drill down into these comments and relationships to see how various team members have interacted with a certain item within a project. This visibility can help to clarify questions about who may be impacted if that item is changed or delayed.

The Death, Finally, of the Blast Email

How this process works depends on the specific tool used. For instance, a rich graphical interface can visually display how one individual’s work connects with the work of every other team member. This insight allows team members to drill down into any component of a product or aspect of a decision, so they can make better decisions in less time. It also includes indicators showing the scope of conversations and associated decisions, so users can immediately reach out to the right person.

“Purposeful collaboration connects the right people to the right work,” Harris says. “It is the antithesis of a blast email sent to hundreds of people.”

Ultimately, the goal is to make the collaborative environment a savvy alternative to slower, cruder communications methods. “It makes everyone’s job infinitely easier,” says Harris.

Technology Adoption vs. Change

It can be tempting to think of technology adoption and change as one in the same. But there are inherent differences, some of which you can see by thinking about them in terms of their graphical representations. If you overlay the traditional Technology Adoption Curve on top of the generally accepted Kübler-Ross Change Curve, does something stand out to you?

I’m pretty sure my 4 year old could tell you that the lines move in opposite directions. Now I know technically the “Y” axes on these graphs measure different things (Number of adopters vs. morale and competence), but hear me out and tell me if this story resonates with your last software rollout.

You just purchased the latest tool that is going to help your team run faster, smoother and with fewer errors. You worked with the vendor and successfully implemented the tool to work with your team’s existing processes. You saw some early wins. The pilot team saw some great improvement and was even able to report some initial ROI that made senior management excited to see more.

Now that the pilot team has proven the software, you’re ready to roll the software out to the entire organization. You create training material, maybe you even put up some posters internally advertising this new software is coming. The company is a buzz with the “New Way of doing business.” You hold a launch party, everyone attends the company mandated training, and the whole project was a success.

2 months later you’re in your SVP meeting explaining to the team why the usage statistics of your software haven’t budged since launch. The projects that were set up in the tool all seem to be behind on their deliverables and some ROI metrics are starting to move into the negative. The SVP wants to know why your tool is broken and what you intend to do to fix it?

You leave the meeting discouraged thinking it’s not the tool, it’s the people how come no one is accepting this “New Way of doing Business?” Basically you’ve hit the Frustration and Depression stage just as your tool adoption is supposed to be ramping up!

Does this sound familiar? Many of us know that forcing change may not be the best way to promote a happy workplace. Given todays need for the short timelines and pressures to create the all so important ROI, there are ways to soften the “Force feeding” of change.

1. Identify and activate your early adopters

Maybe you did have a successful pilot, or even a few successful projects using the tool. Ask the people involved in these early successes to be advocates of your system. Not just to SVPs but to their peers. Have them work with your users to explain how the handled challenges and provide insights on best practices.

2. Don’t replace the process, support it

If you are installing a new tool that completely changes the way your employees do business, and that initiative fails, guess where the blame will lie? Not on the process, that’s intangible but a tool has a name and is easy to blame. Rather than gutting and replacing holistically what you do now, look for ways to integrate your existing processes with the new tool. Explain that the tool is helping to support the current process and adapt it, not replace it.

3. Leverage the community and bring them together

Create a user community for your new tool. This is a place for users to ask questions, post best practices, and find FAQs. Invite your early adopters (see #1) to post items and respond to discussions. If employees feel like everyone is rallying around a tool they will be more willing to accept it. It also frees your time so that you’re not the sole point of contact. BONUS!

4. Arts and Crafts Sessions

One of the hardest challenges is getting new users to actually USE the tool. Don’t ask your users to make the switch 100%. Invite them to try some of the more user friendly or sticky features. If you have a collaboration space, mention them in a comment and ask for a response. If you have a Dashboard, share it with them and ask them what information they would like to see. Invite them to get their feet wet before you ask them to take to cliff diving.

5. Don’t call it the “New Way”

As soon as you mention a new way, game changer, etc. people might instantly put up their guard to the “Old Way” or more likely “Their Way.” It causes people to get defensive even if they don’t necessarily think their way is the best. Call it what it is, A new tool to help them do their job. Don’t let your co-workers be too busy to improve.

Share your Experience

Do you have a successful adoption story? Or perhaps one that was difficult but taught you a lot? Share your story with us via Twitter to continue the conversation.

I’m thrilled to introduce a new version of Jama. Over the weekend, we upgraded Jama to our SaaS customers. This release marks our continued focus on providing organizations and teams a central place to manage and communicate their product definition, development and deployment. At the core of the new features for this release, we’ve linked two concepts together: collaboration and traceability. Over the years, these have been considered separate and disconnected. Traceability ensured coverage and referred to the relationship between test cases and requirements. We see traceability as much more, as the connecting (“steel”) thread between the core business value of the product and the work, down to the item level, performed by every member of the extended product team.

By merging the concepts of traceability with collaboration, we’ve introduced in Jama a set of visualization features that clearly show who across the organization is connected to the work. When someone needs a decision or a question to move forward, they can instantly reach out to the right people for real-time action. Product development is all about negotiations and trade-offs. You start with this beautiful idea of what you want to build, and then the reality of what ultimately comes out at the end requires decisions and compromises. If everyone on your team has a clear understanding of the steel thread, they’ll make the right decisions, navigate through the technical complexities and contribute elegantly to the business outcomes.

For example, the Jama product team captures around 72 product-related decisions per day. This is a one-product, agile team working in one location. The biggest majority of organizations we work with are much larger – consider how many decisions are escaping view from the organization. Conversations that would otherwise be lost in meetings, in email or buried in documents somewhere are captured in the Jama Stream, connected to the work. Now, with the new Connected Users features, users can trace not only the decisions and conversations back to the work, but also the people directly, and indirectly, vested in the outcome of each decision. This insight can dramatically speed the development process and result in better product outcomes.

The Spring release also introduces Relationship Rules, a visual diagram to define and standardize data so users can see how their data fits into the entire product delivery process. This feature prevents users from connecting incorrect data and ensures full traceability.

To learn more about these new features check out the video below, see the press release and read the release notes.

In the first part of this two-part series I described the value of managing risks formally on a software project and listed numerous common risks in various categories. This article describes the various activities associated with the practice of risk management and recommends specific information you should record about each risk you identify.

Risk Management Components

As with other project activities, begin risk management by developing a plan, perhaps using the risk management plan template available at www.ProjectInitiation.com. Small projects can include a concise risk management plan as a section within the overall project plan. Risk management consists of the activities illustrated in Figure 1 and described below.

Risk Assessment

Risk assessment is the process of examining a project to identify areas of potential risk. Risk identification can be facilitated with the help of a checklist of common risk areas for software projects, as I described in the first article in this series. Risk analysis examines how project outcomes might change with modification of risk input variables. In other words, just how could the risk harm your project.

Figure 2: Risk exposure is a function of probability and potential loss.

Risk prioritization helps the project focus on its most severe risks by assessing the risk exposure. Exposure is the product of the probability of incurring a loss due to the risk and the potential magnitude of that loss. I usually estimate the probability from 0.1 (highly unlikely) to 1.0 (certain to happen), and the loss (also called impact) on a relative scale of 1 (no problem) to 10 (deep tapioca). Multiplying these factors together provides an estimate of the risk exposure due to each item, which can run from 0.1 (don’t give it another thought) through 10 (stand back, here it comes!). It’s simpler to estimate both probability and loss as High, Medium, or Low. Figure 2 shows how you can estimate the risk exposure level as High, Medium, or Low by combining the probability and loss estimates.

Risk Avoidance

Risk avoidance is one way to deal with a risk: don’t do the risky thing! You might avoid risks by not undertaking certain projects, or by relying on proven rather than cutting-edge technologies when possible. You might be able to transfer a risk to some other party, such as a subcontractor.

Risk Control

Risk control is the process of managing risks to achieve the desired outcomes. Risk management planning produces a plan for dealing with each significant risk, including mitigation approaches, owners, and timelines. Risk resolution entails executing the plans for dealing with each risk. That’s when you actually control the risk. Finally, risk monitoring involves tracking your progress toward resolving each risk item.

Let’s look at an example of risk management planning. Suppose the “project” is to take a hike through a swamp in a nature preserve. You’ve heard the swamp might contain quicksand, so the risk is that we might step in quicksand and be injured or even die. One strategy to mitigate this risk is to reduce the probability of the risk actually becoming a problem. A second option is to consider actions that could reduce the impact of the risk if it does in fact become a problem. So, to reduce the probability of stepping in the quicksand, we might look for signs of quicksand as we walk and draw a map so we can avoid these areas on future walks. To reduce the impact if someone does step in quicksand, the members of the tour group could rope themselves together. That way if someone does encounter some quicksand the others could quickly pull him to safety.

Even better, is there some way to prevent the risk from becoming a problem under any circumstances? Maybe we build a boardwalk as we go so we avoid the quicksand. That will slow us down and cost some money. But, we don’t have to worry about quicksand any more. The very best strategy is to eliminate the root cause of the risk entirely. Perhaps we should drain the swamp, but then it wouldn’t be a very interesting nature walk. By taking too aggressive a risk approach, you can eliminate the factors that make a project attractive in the first place.

Documenting Risks

Simply identifying the risks facing a project is not enough. We need to write them down in a way that lets us communicate the nature and status of risks throughout the affected stakeholder community over the duration of the project. Figure 3 shows a form I’ve found to be convenient for documenting risks. It’s a good idea to keep the risk list itself separate from the risk management plan, as you’ll be updating the risk list frequently throughout the project. You can download an alternative template for your risk list from www.ProjectInitiation.com. This format includes essentially the same information that’s in Figure 3, but it’s laid out in a way that’s amenable to storing in a spreadsheet or as a table in a word-processing document.

ID: <sequence number or a more meaningful label>
Description: <List each major risk facing the project. Describe each risk in the form “condition – consequence.”>
Probability: <What’s the likelihood of this risk becoming a problem?>	Loss: <What’s the damage if the risk does become a problem?>		Exposure: <Multiply Probability times Loss.>
First Indicator: <Describe the earliest indicator or trigger condition that might indicate that the risk is turning into a problem.>
Mitigation Approaches: <State one or more approaches to control, avoid, minimize, or otherwise mitigate the risk.>
Owner: <Assign each risk mitigation action to an individual for resolution.>		Date Due: <State a date by which the mitigation approach is to be implemented.>

Figure 3: A risk documentation form.

Use a condition–consequence format when documenting risk statements. That is, state the risk situation (the condition) that you are concerned about, followed by at least one potential adverse outcome (the consequence) if that risk should turn into a problem. Often, people suggesting risks state only the condition—“The customers don’t agree on the product requirements”—or the consequence—“We can only satisfy one of our major customers.” Pull those together into the condition-consequence structure: “The customers don’t agree on the product requirements, so we’ll only be able to satisfy one of our major customers.” This statement doesn’t describe a certain future, just a possible outcome that could harm the project if the condition isn’t addressed.

Keep the items with high risk exposures at the top of your priority list to focus your risk-control energy. Set goals for determining when each risk item has been satisfactorily controlled. Your mitigation approaches for some items may focus on reducing the probability, whereas the approach for other risks could emphasize reducing the potential loss or impact. With any luck, some of your mitigation strategies will help you control multiple risk factors.

Risk Tracking

As with other project management activities, you need to get into a rhythm of periodic monitoring. You may wish to appoint a risk manager for the project. The risk manager is responsible for staying on top of the things that could go wrong, just as the project manager stays on top of the activities leading to project completion. It’s a good idea to have someone other than the project manager serve as the risk manager. The project manager is focused on what he has to do to make a project succeed. The risk manager, in contrast, is identifying factors that might prevent the project from succeeding. In other words, the risk manager is looking for the black cloud around the silver lining that the project manager sees. Asking the same person to take these two opposing views of the project can lead to cognitive dissonance; in an extreme case, his brain can explode.

Keep the top ten risks highly visible and track the effectiveness of your mitigation approaches regularly. New risks might float up into the top ten as you gradually beat the initial list of top priority items into submission. You can drop a risk off your radar when your mitigation approaches have reduced the risk exposure from that item to an acceptable level. Don’t conclude that a risk is controlled simply because the selected mitigation action has been completed. Controlling a risk might require you to change the risk control strategy if you conclude it isn’t working.

A student in a seminar once asked, “What should you do if you have the same top five risks week after week?” A static risk list suggests that your risk mitigation actions aren’t working. Effective mitigation actions should lower the risk exposure as the probability, the loss, or both decrease over time. If your risk list isn’t changing, check to see whether the planned mitigation actions have been carried out and whether they had the desired effect.

Also, look for new risks that might arise during the course of the project. Conditions can change, assumptions can prove to be wrong, and other factors might lead to risks that weren’t apparent or perhaps did not even exist at the beginning of the project. Escalate risks that aren’t being controlled to the attention of senior managers or other stakeholders. They can then either stimulate corrective actions or else make a conscious business decision to proceed in spite of the risks.

Learning from the Past

We can’t predict exactly which of the many threats to our projects might come to pass. However, most of us can do a better job of learning from previous experiences to avoid the same pain and suffering on future projects. As you begin to implement risk management approaches, record your actions and results for future reference. The risks are out there. Find them before they find you.

Also read Knowing Your Enemy: An Introduction to Risk Management, Part 1

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.

As the new training manager at Jama I’ve been working with our team in 2014 to bring you new educational options, and I’m happy to announce that our first set is now available for free to existing customers.

It’s my pleasure to introduce the tutorial set: Get Started with Jama. These short videos will have you up and running in Jama in less than an hour. All of the videos are under five minutes long, and many run half that. You can access the videos via the welcome screen in Jama.

If you’ve been a customer for a while, you may have turned the welcome screen off, so here’s how you turn it on again. First, click on your name in top right-hand corner.

Then select this box to access the welcome screen again.

Log out and back in, and you’ll have the screen. Click Learn Jama Basics, and you’re there.

Do you have new employees? Show them this post and get them started quickly in the tool. Need a refresher on functionality you haven’t used in a while? Watch what you need. Please, feel free to share this with anyone who’s using Jama. We want you to be able to pick up and use our tool as easily as possible.

We’d love to hear what you think of these videos! Feel free to leave a comment below, or if you’d prefer to reach out to us directly, email us at [email protected]. Keep an eye out for more Jama training announcements soon.

In Part 1 of this series, adapted from my book Practical Project Initiation, I shared four best practices that can help you lay the foundation for a successful project and two practices that are useful for project planning. This article continues the series by describing additional project planning best practices and several practices for estimating the work needed to complete the project.

Planning the Project

Practice #7: Develop planning worksheets for common large tasks. If your team frequently undertakes certain common tasks—such as implementing a new class, executing a system test cycle, or performing a product build—develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he must tackle. People work in different ways and no single person will think of all the necessary tasks, so engage multiple team members in developing the worksheets. Tailor the worksheets to meet the specific needs of individual projects. I’ve used such worksheets when creating eLearning versions of my training courses. They helped me avoid overlooking an important step in my rush to finish the project.

Practice #8: Plan to do rework after a quality control activity. I’ve seen project plans that assumed every test will be a success that lets you move on to the next development activity. However, almost all quality control activities, such as testing and peer reviews, find defects or other improvement opportunities. Your project schedule should include rework as a discrete task after every quality control task. Base your estimates of rework time on previous experience. If you collect a bit of data, you can calculate the average expected rework effort to correct defects found in various types of work products. And if you don’t have to do any rework after performing a test, great; you’re ahead of schedule on that task. This is permitted in all fifty states and in many other countries. Don’t count on it, though.

Practice #9: Manage project risks. If you don’t identify and control project risks, they’ll control you. A risk is a potential problem that could affect the success of your project. It’s a problem that hasn’t happened yet—and you’d like to keep it that way. Simply identifying the possible risk factors isn’t enough. You also have to evaluate the relative threat each one poses so you can focus your energy where it will do the most good.

Risk exposure is a combination of the probability that a specific risk could materialize into a problem and the negative consequences for the project if it does. To manage each risk, select mitigation actions to reduce either the probability or the impact. You might also identify contingency plans that will kick in if your risk control activities aren’t as effective as you hope.

A simple risk list doesn’t replace a plan for how you will identify, prioritize, control, and track risks. Incorporate risk tracking into your routine project status tracking. See Chapter 6 of Practical Project Initiation for an overview of software risk management.

Practice #10: Plan time for process improvement. Your team members are already swamped with their current project assignments. If you want the group to rise to a higher plane of software development capability, though, you’ll have to invest in process improvement. This means you’ll need to set aside some time from your project schedule for improvement activities. Don’t allocate one hundred percent of your team’s available time to project tasks and then wonder why they don’t make any progress on the improvement initiative.

Some process changes can begin to pay off immediately, but you won’t reap the full benefit from other improvements until the next project. Process improvement is a strategic investment in the organization. I liken process improvement to highway construction: It slows everyone down a little bit for a time, but after the work is done, the road is a lot smoother and the throughput is greater.

Practice #11: Respect the learning curve. The time and money you spend on training, self-study, consultants, and developing improved processes are part of the investment your organization makes in sustained project success. Recognize that you’ll pay a price in terms of a short-term productivity loss—the learning curve—when you first try to apply new processes, tools, or technologies. Don’t expect to get fabulous benefits on the first try, no matter what the tool vendor or the consultant claims. Make sure your managers and customers understand the learning curve as an inescapable consequence of working in a rapidly changing, high-technology field.

Estimating the Work

Practice #12: Estimate based on effort, not calendar time. People generally provide estimates in units of calendar time. I prefer to estimate the effort (in labor-hours) associated with a task, and then translate the effort into a calendar-time estimate. A twenty-hour task might take 2.5 calendar days of nominal full-time effort, or two exhausting days. However, it could also take a week if you have to wait for critical information from a customer or stay home with a sick child for two days. I base the translation of effort into calendar time on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears.

If you track how you actually spend your time at work, you’ll know how many effective weekly project hours you have available on average. Tracking time like this is illuminating. Typically, the effective project time is only perhaps fifty to sixty percent of the nominal time team members spend at work, far less than the assumed one hundred percent effective time on which so many project schedules are planned.

Practice #13: Don’t over-schedule multitasking people. The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Excessive multitasking introduces communication and thought process inefficiencies that reduce individual productivity. I once heard a manager say that someone on his team had spent an average of eight hours per week on a particular activity, so therefore she could do five of them at once. Forty hours per week divided by eight is five, right? In reality, she’ll be lucky if she can handle three or four such tasks. There’s just too much friction associated with multitasking.

Some people multitask more efficiently than others, even thriving on it. But if certain of your team members thrash when working on too many tasks at once, set clear priorities and help them do well by focusing on just one or two objectives at a time.

Practice #14: Build training time into the schedule. Estimate how much time your team members spend on training activities each year and subtract that from the time available for them to work on project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way.

Recognize that the high-tech field of software development demands that all practitioners devote time to ongoing education, both on their own time and on the company’s time. Arrange just-in-time training when you can schedule it, as the half-life of new technical knowledge is short unless the student puts the knowledge to use promptly. Attending a training seminar can be a team-building experience, as project team members and other stakeholders hear the same story about how to apply improved practices to their common challenges.

Practice #15: Record estimates and how you derived them. When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary. It will also help you improve your estimation process. Train the team in estimation methods, rather than assuming that every software developer and project leader is naturally skilled at predicting the future. Develop estimation procedures and checklists that people throughout your organization can use.

The Wideband Delphi method is an effective group estimation technique. This technique asks a small team of experts to anonymously generate individual estimates from a problem description and reach consensus on a final set of estimates through iteration. Participation by multiple estimators and the use of anonymous estimates to prevent one participant from biasing another make the Wideband Delphi method more reliable than simply asking a single individual for his best guess. Chapter 11 of Practical Project Initiation presents a tutorial on the Wideband Delphi estimation method.

The final article in this series will describe two additional estimation tips, along with several good practices for tracking your progress and learning how to plan and manage future projects more effectively.

Also read Project Management Best Practices, Part 1
Also read Project Management Best Practices, Part 3

Today we are rolling out our Fall 2013 Release and with it, continuing to enhance the most collaborative and efficient product delivery platform on the market. With the newest version of Jama, we are tackling one of the most fundamental challenges companies face when trying to accelerate their time to market: change.

In today’s technology-driven economy, companies are being driven to deliver better products to market faster in order to survive, let alone grow and succeed. The most innovative companies in their markets today have one key focus in common: delivering a fantastic customer experience. They embrace frequent customer and stakeholder feedback loops and the resulting change required to ensure they’re completely aligned on delivering customer value. The need to change is an opportunity to do something better. Product delivery is an iterative process and companies who embrace this not only get projects completed on time and products to market faster, they deliver what the customer wants, learn, and continually improve. Companies that continue to look at change as “churn” that needs to be controlled and mitigated will be left in the dust.

How does Jama Fall Release help you embrace change as an opportunity and move to a more iterative development process? As your product moves through the phases of define, build and test, Jama helps you connect the people involved, so everyone knows what you are building and why. We’ve also enhanced our integration capabilities, providing two-way data exchange between Jama and the most popular developer tools.

All the new capabilities align to improve the flow of information and boost collaboration to ease and shorten product delivery cycles. Watch the video below for specifics on what is new in the Fall 2013 Release.

In the previous two articles in this series, adapted from my book Practical Project Initiation, I’ve described fifteen practices the project manager can apply to lay the foundation for a successful project, plan the project, and estimate the work to be done. In this final article I share two additional estimation practices, three good practices for tracking your progress throughout the project, and one practice for learning how to execute your future projects more successfully.

Estimating the Work (continued)

Practice #16: Use estimation tools. Many commercial tools are available to help project managers estimate entire projects. Based on equations derived from large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff allocation options. They’ll also help you avoid the “impossible region,” combinations of product size, effort, and schedule where no known project has been successful. The tools incorporate a number of “cost drivers” you can adjust to make the tool more accurately model your project, based on the technologies used, the team’s experience, and other factors. You can compare the estimates from the tools with the bottom-up estimates generated from a work breakdown structure. Reconcile any major disconnects so you can generate the most realistic overall estimate.

Practice #17: Plan contingency buffers. Projects never go precisely as planned. The prudent project manager incorporates budget and schedule contingency buffers at the end of phases, dependent task sequences, or iterations to accommodate the unforeseen. Use your project risk analysis to estimate the possible schedule impact if several of the risks materialize, then build that projected risk exposure into your schedule as a contingency buffer. An even more sophisticated approach is critical chain analysis, a technique that pools the uncertainties in estimates and risks into a rational overall contingency buffer. Chapter 10 of Practical Project Initiation is all about contingency buffers.

Your manager or customer might view these contingency buffers as padding, rather than as the sensible acknowledgment of reality that they are. To help persuade skeptics, point to unpleasant surprises on previous projects as a rationale for your foresight. If a manager elects to discard contingency buffers, he has tacitly absorbed all the risks that fed into the buffer and assumed that all estimates are perfect, no scope growth will occur, and no unexpected events will take place. Sound realistic to you? Of course not. I’d rather see us deal with reality—however unattractive—than to live in Fantasyland.

Tracking Your Progress

Practice #18: Record actuals and estimates. Unless you record the actual effort or time spent on each project task and compare them to the estimates, your estimates will forever remain guesses. Someone once asked me where to get historical data to improve her ability to estimate future work. My answer was, “If you write down what actually happened today, that becomes historical data tomorrow.” It’s really not more complicated than that. Each individual can begin recording estimates and actuals, and the project manager should track these important data items on a project task or milestone basis. In addition to effort and schedule, you could estimate and track the size of the product, in terms of requirements, user stories, lines of code, function points, GUI screens, or other units that make sense for your project.

Practice #19: Count tasks as complete only when they’re one hundred percent complete. We give ourselves a lot of partial credit for tasks we’ve begun but not yet fully completed: “I thought about the algorithm for that module in the shower this morning, and the algorithm is the hard part, so I’m probably about sixty percent done.” It’s difficult to accurately assess what fraction of a sizable task has actually been finished at a given moment.

One benefit of using inch-pebbles (see Practice #6 in Part 2 of this series) for task planning is that you can break a large activity into a number of small tasks (inch-pebbles) and classify each small task as either done or not done—nothing in between. Project status tracking is then based on the fraction of the tasks that are completed and their size, not the percentage completion of each task. If someone asks you whether a specific task is complete and your reply is, “It’s all done except…,” then it’s not done! Don’t let people “round up” their task completion status. Instead, use explicit criteria to determine whether an activity truly is completed.

Practice #20: Track project status openly and honestly. An old riddle asks, “How does a software project become six months late?” The rueful answer is, “One day at a time.” The painful problems arise when the project manager doesn’t know just how far behind (or, occasionally, ahead) of plan the project really is. Surprise, surprise, surprise.

If you’re the PM, create a climate in which team members feel it is safe for them to report project status accurately. Run the project from a foundation of accurate, data-based facts, rather than from the misleading optimism that can arise from the fear of reporting bad news. Use project status information and metrics data to take corrective actions when necessary and to celebrate when you can. You can only manage a project effectively when you really know what’s done and what isn’t, what tasks are falling behind their estimates and why, and what problems, issues, and risks remain to be tackled.

The five major areas of software measurement are size, effort, time, quality, and status. It’s a good idea to define a few metrics in each of these categories. Instilling a measurement culture into an organization is not trivial. Some people resent having to collect data about the work they do, often because they’re afraid of how managers might use the measurements. The cardinal rule of software metrics is that management must never use the data collected to either reward or punish the individuals who did the work. The first time you do this will be the last time you can count on getting accurate data from the team members.

Learning for the Future

Practice #21: Conduct project retrospectives. Retrospectives (also called postmortems and post-project reviews) provide an opportunity for the team to reflect on how the last project, phase, or iteration went and to capture lessons learned that will help enhance your future performance. During such a review, identify the things that went well, so you can create an environment that enables you to repeat those success contributors. Also look for things that didn’t go so well, so you can change your approaches and prevent those problems in the future. In addition, think of events that surprised you. These might be risk factors to look for on the next project. Finally, ask yourself what you still don’t understand about the project, so you can try to learn how to execute future work better.

It’s important to conduct retrospectives in a constructive and honest atmosphere. Don’t make them an opportunity to assign blame for previous problems. Chapter 15 of Practical Project Initiation describes the project retrospective process and provides a worksheet to help you plan your next retrospective. It’s a good idea to capture the lessons learned from each retrospective exploration and share them with the entire team and organization. This is a way to help all team members, present and future, benefit from your experience.

The twenty-one project management best practices I’ve described in this series of articles won’t guarantee your project a great outcome. They will, however, help you get a solid handle on your project and ensure that you’re doing all you can to make it succeed in an unpredictable world.

Also read Project Management Best Practices, Part 1
Also read Project Management Best Practices, Part 2