Project Management Articles > Alan S. Koch

Alan S. Koch

Alan S. Koch Alan S. Koch, PMP is a speaker and writer on effective Project Management methods. He is a certified Project Management Professional and President of ASK Process, Inc., a training and consulting company that helps companies to improve the return on their software investment by focusing on the quality of both their software products and the processes they use to development them. His 28 years in software development include 14 years designing, developing and maintaining software and over 13 years in quality assurance and software process improvement. He was with the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU) for 13 years, where he became familiar with the Capability Maturity Model (CMM), earned the authorization to teach the Personal Software Process (PSP), and worked with Watts Humphrey in pilot testing the Team Software Process (TSP).

Among Mr. Koch's credits are Agile Software Development: Evaluating the Methods for your Organization (Artech House: 2005) and "TSP can be the Building Blocks for CMMI," (Crosstalk Magazine, March 2005). He has consulted with a variety of software organizations in their process improvement programs. Hundreds of professionals in numerous organizations and government agencies have taken his classes on project management, process improvement, and software quality and responded with high praise for his training. Mr. Koch also contributed to the accomplishment of several successful CMM-Based SPI efforts, and was a team member on several CMM assessments and CMMI appraisals. He has presented at numerous recent software quality and process conferences, taught as an adjunct professor of Computer Science, and has mentored students in CMU's Master of Software Engineering (MSE) Program.

Mr. Koch is a Senior Member of IEEE, an SEI-authorized PSP Instructor and TSP Coach candidate, an SEI Transition Partner for the PSP and TSP, and a member of the board of the National Speakers Association, Pittsburgh Chapter.

 Beware of Shiny New Tools!
There are scads of cool DevOps tools out there, but practice makes perfect.
DevOps maturity does require a good toolset, but DevOps is much, much more than just implementing tools. Read more ...

Archived articles -- Accessible to All

How Does DevOps Work in Large IT Departments?
DevOps can work in large organizations too, but they will have different challenges.
It's tempting to talk about DevOps like it's a magical cookbook of utopian solutions. Of course, that's not true — and when we're dealing with the large enterprise world most of us live in, it's especially not true. Read more ...

DevOps In Action: Ops on Dev Teams
Building great products is one thing. Deploying them is another. Ops can help.
There is no central authority and no DevOps standard. There is no single "right way" to go down the DevOps road. Read more ...

Automated Testing - DevOps Enabler
Automate everything you can, but not necessarily everything
"Automate everything you can." This DevOps principle propels automated testing into a primary enabling position for any organization that embarks on a DevOps journey. No longer an option. No longer something we should do. Read more ...

What DevOps Is and Is Not
DevOps can be difficult to define. Alan Koch provides a valuable introduction, and explains why you should automate everything you possibly can.
There is no central authority and no DevOps standard. There is no single "right way" to go down the DevOps road. Read more ...

Taming the Wild Business Rule
How do you find business rules important to your project if no one knows what they are, or where they are, or even what you're talking about? Elicitation, baby!
Business rules can be a source or cause of requirements for your project. For example, a Business Rule may specify how the system or the business process must do certain things. Or some of the steps in the business process or functionality of the system must enforce some particular rules. Read more ...

Role of the Business Analyst in User Acceptance Testing
Testing isn't over when your QC team signs off on defects, it's just getting started.
User Acceptance Testing (UAT) provides an important check to be sure that the business needs have been fully and correctly met, and that they have been met in a way that is acceptable to the business and the users. Participation in UAT provides the BA with a significant opportunity to ensure that the solution provides precisely what the business needs. Read more ...

When Agile Developers Test Well
Lip service is sometimes given to the idea that testing starts in development. But what does that mean for productivity?
Today we think of productivity as writing lots of code. Testing is a different activity that involves someone else's productivity. Read more ...

Role of the BA in User Acceptance Testing
Business analysis is an invaluable resource for truly insightful User Acceptance Testing.
Participation in UAT provides the BA with a significant opportunity to ensure that the solution provides precisely what the business needs. Read more ...

Agile Teams Need Generalizing Specialists
In a methodology that demands every team member be able to do every task, how do specialists fit in?
Can we achieve the Agile ideal of full and open collaboration when our team members are not generalists? Is there a place for specialists on Agile teams? Read more ...

Is the Agile Manifesto Dangerous?
When a colleague takes a stand against the "danger" posed by the Agile Manifesto to young software engineers, Alan Koch responds -- decisively.
Magdy, everything you write about Agile methods is true. Many people abuse the concepts, misunderstand their responsibilities, and end up hacking rather than engineering software. Read more ...

Agile Testing: Technical Excellence
Technical excellence has to mean more than throwing the code over a wall at your testers. If you start your agile project by writing code quickly, you're bound to finish it by testing slowly, and at length.
The founders of the Agile movement didn't get everything right. I believe they severely understated their case on Agile Principle #9. Excellence "enhances" Agility? Enhances?!?! That is like saying that breathing might be a good idea! Read more ...

Agile Testing: Pair Testing
Pair programming is widely recognized, if often poorly understood, as a valued practice for Agile teams. But have you heard about pair testing?
Pair Testing is a natural extension of Pair Programming. If we can do better coding by pairing, it stands to reason that pairing will result in better testing and a better delivered product. Read more ...

No Mini-Waterfalls!
Testing belongs in the entire sprint, not dribbling over a mini-waterfall at the end of the sprint.
Development teams have used a waterfall approach for so long that they can't imagine working in any other way. Read more ...

What Is Agile Testing?
Just because the Agile Manifesto doesn't explicitly "test" or "quality" doesn't mean you get to skip it.
The words "test" and "quality" do not show up in the Agile Manifesto or the 12 Agile Principles. But these documents contain many statements that imply the need for quality and testing. Read more ...

Agile Compromises: Being Agile in the Face of Reality
It's not a question of whether or not your team is agile, but how agile your team can realistically be.
Agile Values and Principles are quite different from traditional software development approaches, but many organizations have found success with them. So how hard can it be to use them? Read more ...

Agile Mastery: Doing, Understanding, and Being
Where does your team land on the Agile Mastery scale? Understanding where you are can help you move up the ladder.
The teams who struggle with Agility tend to be singularly focused on the doing, while the teams that epitomize Agile Clockwork don't merely do Agile -- they are Agile! Read more ...

Getting Started with Secure Software Development
Don't let perfectionism stand in the way of improvements to your software security.
Three of the 7 Touchpoints are things that we can get started on today: Code Review, Risk Analysis, and Security Requirements. Read more ...

Secure Software: Don't Be the Next Target!
What more can you do to keep your systems secure? So glad you asked...
"We have a firewall. And strong passwords. And we encrypt sensitive data. And we use a virus-scanner. And… Of course our systems are secure!" We wish! Read more ...

Project Management vs. Service Management
Remember project scope while you are defining your product scope.
You realize that an important early challenge will be to define the Product Scope and get all of the Stakeholders' agreement on it. But what about Project Scope? Read more ...

ITIL in an IT Services Company
Why you should never try to "implement" ITIL, and other practical considerations about IT best practices.
The key difference between companies who have gotten real benefit out of these frameworks and those that simply wasted money boils down to their approach. Read more ...

Process Genesis: Chapter 2 of 2 – In the Department of Eden
How did we get here? What does it all mean? Who thought it was a good idea to form a committee?
The Lord God hired a man and assigned him the Role of Process Owner, and the man took on that Role. Now the Lord God had planted a department in the east, in Eden; and there he put the man he had hired. Read more ...

Process Genesis*: Chapter 1 of 2 – Creation
How did we get here? What's the meaning of it all? Where did that big binder come from?
In the beginning, God said, "Let us create!" And the unnamed Us asked, "What is this 'Create'?" And God said, "Let there be Process." And it was so. Read more ...

Little ITIL®, Big Results
Steps 7 thru 10: Beyond Getting Started
Steps 7-10 turn new IT practices into organizational habits (almost).
This new mode of operation transforms IT from a mere supplier of services to an enabler of business success. Read more ...

Little ITIL®, Big Results
Step 6 of 10: Talk About improvements
And Step 6 is what? "Talk"?… Again?
This talking is aimed at ensuring that each improvement we have made (and the benefits that people have enjoyed because of them) are recognized and appreciated. The purpose of this is far more than to get pats on the back. Read more ...

Little ITIL®, Big Results
Step 5b of 10: Making your first improvement
Once you have spotted the low-hanging fruit, you can begin your first improvement project. Sweet!
Improvements seem so benign, but in the real world, they present us with real challenges. Read more ...

Little ITIL®, Big Results
Step 5: Pick the Low-Hanging Fruit (Part 1 - Choose Your First Improvements)
Alan explains how to spot the improvement efforts most likely to yield a sweet payoff.
We can't fix everything all at once! So where do we start? We start with the Low-Hanging Fruit. Read more ...

Little ITIL®, Big Results
Step 4 of 10: Talk About the Score
Once you know the score, it's time to talk about what it means.
This fourth step of the process is focused on restating the complaints you are hearing in terms of metrics. You do that by showing both your customers and your IT Staff what the metrics say, and by probing to see if other metrics are needed to address some complaints. Read more ...

Little ITIL®, Big Results
Step 3 of 10: Know the Score
If you're going to be a player, you have to know the score.
Having begun dialogs that will continue in all of the even-numbered steps, you now need to turn inward. You have heard about problems and opportunities for improvement from all sides. Read more ...

Little ITIL®, Big Results
Step 2 of 10: Talk About Getting Started
If you want to get things done, you'd better start by listening.
Before you can get started on anything of consequence to improve your IT services and people's perception of them, you must connect with those people. Read more ...

ITIL — Why Should I Care?
If you haven't heard of ITIL®, you will. But should you care? If you're in IT or in a related PMO; a business person interfacing with IT for services; or a process implementer, process consultant, or just plain process-curious, we maintain that you SHOULD care about ITIL. Read more ...

Quality = Business Value - Part 2
If Quality is delivering Business Value, how do you measure it?
Every project must be justified in order to be approved and funded. Some of us as Project Managers are involved in this justification process, and others of us are given responsibility for projects after they have been justified and approved. Read more ...

Quality = Business Value
What does Quality mean to you? Most of the common definitions don't get us as far as you might think.
How does your organization define "Quality"? Has a definition of "Quality" ever been formally adopted? Is there even a common understanding of what is meant by the word among all of the various people in your organization? Read more ...

Blurring the Line between Dev & QA 
Alan examines how we got here from there, and whether we should consider going back.
Before the dawn of time (in the late 1800s), large corporations and research organizations had "Computer rooms" -- vast seas of desks at which people sat and scratched pencils down to nubs as they filled reams of papers with numbers. Their job title? "Computer." Read more ...

How to Estimate Program Size
1, 2, 3… How do you estimate lines of code required for a program that hasn't been written?
If a new system is built, how do you guess at how many lines of code there will be? You possibly can guess at the number of programs from looking at the requirements but how do you guess the number of lines involved for each program? Read more ...

How Much Quality Can We Afford?
Alan Koch illustrates how the math works out as we add and manipulate hours spent reviewing code and requirements.
Sure, it might be nice to build a higher quality product. But how much quality can we really afford? Well, let's break out our Cost of Quality Calculator and try out the numbers. Read more ...

The Agile Customer: Making Your Supplier a Bit More Agile
Practical options for injecting some Agility into your project, in spite of the Waterfall raining down on you from your supplier.
Agility is relatively easy when you control all of the parts of the project. But when others are involved, barriers to Agility can begin to spring up. Read more ...

Fix It Fast vs. Fix It Right
A deliberate Root Cause Analysis process will help you get to the bottom of a problem and fix it permanently, not just quickly.
Your choices when dealing with a problem are to 1) fix it fast, or 2) fix it right. They were trying to do both of them at the same time, which often isn't possible. Read more ...

Employee Recognition in an Agile Team
Can you reward your agile team without causing friction and competition?
The Agile methods are designed to make the work environment itself a motivator for the team members. But well-placed recognition can be a powerful addition—if it is done in an Agile way! Read more ...

What Makes a Project "Agile"? Part 7: Iterative Planning
Of course Agile teams plan! But they don't necessarily try to get it all right the first time.
Every project begins with planning, and Agile projects are no different. There is no point in pressing forward until we set everyone's expectations about what will be going on. Read more ...

What Makes a Project "Agile"? Part 6: Incremental Delivery
Incremental Development works—which is why the Agile methods use it.
People have been developing systems incrementally for decades. And although Agile projects build the product in smaller increments than we traditionally think of, the basic premise is the same. Read more ...

The Essence of Agility: Progressive Requirements Elaboration – Part 5
The agile version detailed requirements isn't no requirements. Truly agile teams will capture requirements and documentation as needed.
Progressive requirements elaboration allows an Agile team to balance their customer's need for flexibility with their own need to plan their work. Read more ...

The Essence of Agile: Embracing Lean Principles – Part 4
Yes, Lean principles can apply to software projects, and on Agile projects they do.
As much as those of us who have been fighting the concept of "software factories" might hate the idea, the same principles that underpin Lean Manufacturing are quite useful in software projects. (YIKES!) Read more ...

The Essence of Agility: Small, Self-Directed Teams – Part 3
Are they being Agile, or just lazy? One way to tell is to watch the team's interaction with their management.
"Small" is easy to see. "Self-Directed" is less obvious. What behaviors would indicate that a team is self-directing? Read more ...

Customer Focus: What makes a project "Agile"? – Part 2
Is the team "Agile," as they claim, or are they using that term as a cloak for a lack of discipline? One way to know is to observe what drives their activity: do they do what is cool, or do they do what the customer values?
It is all about our customer. All! An Agile team will do everything in their power to maintain continuous (or at least regular) contact with their customer, because that contact is essential to their ability to produce what the customer needs. Read more ...

The Essence of Agility: What makes a project "Agile"? – Part 1
There's agile, and then there's Agile. How can we tell the difference? As usual, actions—or in this case, behaviors—speak louder than words.
I've been told that Agility means, "We'll just wing it, and when we run out of money, we'll ask for more." This and other such statements show that many people don't understand what Agility is all about. Read more ...

Why Agile? Learning to Develop Software Successes
Agile development methods are not new, and they won't solve all our problems -- which is exactly what makes them worth adopting.
And now along comes "Agile." Why should we pay any attention? Why should we expect this is anything more than the latest brand of snake oil?
Read more ...

Did That Process Change Work? Four Steps to Better Processes
So you made some changes to the way you do your projects. Did those changes make a difference? How can you know?
"Coming up with good ideas for process changes is no different from coming up with good ideas for product requirements; it is only the first step."
Read more ...

What is the Business Analyst's Role? Four Steps to a Clear Answer
The Business Analyst role can overlap several others in your organization, but this simple approach will minimize conflicts over responsibilities.
So, where does the Business Analyst (BA) role end and the Project Manager (PM) role begin? I see lots of opportunity for toes to be stepped on if we implement these things in my organization!
Read more ...

Investing in Quality: When is "Enough" Enough?
Alan walks you through the basics of harvesting your quality data and putting it to use.
There is no doubt that we need to invest in producing a quality product. But it is not clear how much we should invest. So, how do we find that sweet spot?
Read more ...

Yes, You Can Negotiate Project Constraints!
Good estimates are the key to negotiating reasonable project constraints -- even when your sponsor isn't asking for them.
Although it may not seem to be true, we can negotiate unrealistic project expectations. And the key is to do a good job of estimating what it really will take to do the project. Read more ...

ITIL: A Foundation for Project Success
Can a model that is not about projects help us with our development projects? Absolutely!
ITIL can help us to assure the quality of the systems we develop by providing the basis for understanding the business need and taking action on that understanding. ITIL can be our foundation for project success by defining the context for our project and for the product we will build! Read more ...

Testing Is NOT Quality Assurance
The bright line between Quality Assurance and Quality Control, and a wide array of QA activities we may be overlooking on our projects.
We in the software industry have gotten into a bad habit of using the term "Quality Assurance" to refer to things like testing and technical reviews, which are actually Quality Control activities. We've been doing this for so long, and so consistently that most of us don't even know what true Quality Assurance is! Read more ...

Quality That is Worth the Cost
Quality may be an intangible, but that doesn't meant it has to be invisible. Here's how to manage quality by the numbers.
We never have enough money. We never have enough time. We are always under pressure to get more and more done with fewer and fewer resources. With so much pressure, we can't afford to waste time (or money) on Quality Assurance work that isn't necessary. But how can I know which activities are worth the cost? Read more ...

Placing the Quality Bet
The time you need for reviews is already built into your schedule. Just look under "Testing."
We would love to do the "right" thing quality-wise, but there never seems to be a good opportunity to try. Where are we to find the time to add reviews to the already ridiculously tight schedule? Read more ...

Help! The Testers Want to Break the Bank
Four possible strategies for improving quality on your project, plus guidance on deciding whether quality improvement is even called for.
I analyzed the project, I figured out what needs to be done, and I laid out an aggressive but achievable schedule. And then the testers cried "foul!" They tell me that they need three times as much time to ensure a quality product, and that the project is doomed to failure if their demands are denied. Read more ...

High-Quality Unit Tests
Believe it or not, your developers want to get better at unit testing -- a lot better. Here's how you can help them.
Most software developers are not good at unit testing. This is not surprising for many reasons. First, they have generally never been trained in how to do it. Read more ...

Planning for Quality
Without proper attention to defining what we mean by "good" and then planning for it, achieving the level of quality we need is far from assured.
A good friend of mine (I'll call him "Ralph" to protect the guilty) had just spent several days planning his new software project. "What a job!" he exclaimed. "But it was worth it. I'm not leaving anything up to chance this time!" Read more ...

Quality is Conformance OF Requirements
Why parroting your customer's requirements isn't enough, and how to communicate better.
Anything that people produce may be defective, and that includes the specifications that they write. And if the specification is wrong, then how can we say that a system that conforms to it is "high-quality"? Read more ...

Building High-Quality Software: Establishing a culture of quality
Are you holding QA responsible for product quality? They can measure it, but the source of quality is much higher up the company ladder.
When there is a quality problem with our products, where do we look to solve it? If we look to Quality Assurance, we will be disappointed. Read more ...

Reducing Your Cost of Quality
Ways to assess and communicate the true Cost of Quality, and how you can reduce it.
How high is your Cost of Quality? The answer might surprise you. Yes, it includes reviews, the QA infrastructure, and preparing tests—those are your "Appraisal Costs." But how high are your "Failure Costs"—the cost of defects? Read more ...

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Got a Question?
Drop us an email or call us toll free:
Learn more about ProjectConnections, our contributors, and our membership levels and product options.