How To Use Microsoft Project: Task Type

One of the more confusing aspects of Microsoft Project is Task Type.  Task Type can be set to "Fixed Units", "Fixed Work", or "Fixed Duration" for each task.

How to Set Task Type

You can set task type in a couple ways:

1. If you select a task or tasks and go to task information (under project in the menu or right click and its there as well) you will find task type in the advanced tab.

2. If you go to window and click Split when in the GANTT chart view, you get a Task Form at the bottom where you can set the Task Type.

  If you select all your tasks, you can set the Task Information for every task to the same Task Type – this will lead to less confusion when you are adjusting your plan because all the task types will be consistently set.

Effort Driven

There is also a check box (which is checked by default) that says that tasks are “Effort Driven”.  When this is checked, it is assumed that work stays constant even if you adjust the other two measures.  So for example, if you change a 40 hour task from 1 week duration to 2 weeks duration, project will keep the 40 hours of work but decrease the number of resources required to compensate (only 50% of a resource in this case).

This may not be what you want and I find particularly with using Fixed Duration having this turned off is highly desirable because want to adjust the work, not the units.  For example, what I want is to tell project, “I want to schedule this task with 1 person for 2 weeks” and have it calculate work to be 80 hours.  If I adjust the schedule to be 3 weeks, I want the work to increase by 50%.  Similarly, if I am working in Fixed Duration and I double the resources, I want the duration to stay constant and for the work to double.  This will only happen if “Effort Driven” is turned off. 

How Task Type Works

Any task can be adjusted using three measures: Units, Duration or Work.  Because each measure is dependent on the other, at least one of the other two must be impacted.  By changing the task type, you are telling project which measure you are going to adjust and which measure should be automatically re-calculated.  Below is a chart that shows how Project reacts based on the task type:

 

Field that you change	Field calculated if the task is Fixed Units	Field calculated if the task is Fixed Work	Field calculated if the task is Fixed Duration
Work	Duration is recalculated	Duration is recalculated	Units are recalculated
Duration	Work is recalculated	Units are recalculated	Work is recalculated
Units	Duration is recalculated	Duration is recalculated	Work is recalculated

Basic Tips for Using Task Type Efficiently

Here are some basic tips to using Task Type efficiently and to avoid confusion:

• Pick the task type that makes sense for you and use it consistently.  I tend to think in Duration with Effort Driven turned off first and what I want is to calculate the number of hours (and therefore cost) required to do the work.  Other PMs like thinking in work instead and want to adjust the schedule instead.  Pick an approach before you start and be consistent with it.
• You can switch the task type without impacting your plan.  Therefore, feel free to change the task type for the specific scenarios below.

Scenarios to use Specific Task Types

Fixed Duration

I used Fixed Duration when I have a good understanding of the schedule and the team and I want to calculate cost/effort.  A good example of this is doing a plan for requirements gathering interviews.  I know that I have 2 weeks of interviews, 1 week of documentation and 2 days of client review and I know that I need a Business Analyst and a Technical Architect in each one at 100%.  Fixed Duration works really well because I can adjust the schedule really easily and the work effort is calculated for me.

Another good use for Fixed Duration is % allocations for overhead resources.  Project Managers for example tend to be used on an overhead basis for the duration of the project on a fairly constant basis.  If the project takes longer you will need more project management.  It’s also easier to think of assigning a PM at 30% to a project for the entire duration than to say, “I need 85 hours of project management for this project).  With Fixed Duration, you can simply assign the PM for the entire duration and adjust the % allocation and the work effort is automatically calculated.

Fixed Work 

A good use of Fixed Work is when you want to try and fit a fixed amount of hours into a fixed schedule.  By fixing the work, you can adjust the number of resources you need to impact the duration.  For example, let’s assume you have 1280 hours of work and you want to try and jam that work into a fixed 8 week period.  With Fixed Work turned on, you can set the allocation of resources to 400% in order fit the fixed amount of work into a duration you wish.

Fixed Units

I generally find that using Fixed Units is my least desirable option simply because in most real world scenarios adjusting the number of resources required is the most flexible option.

One scenario where Fixed Units might be appropriate is for department planning.  In a department, the number of fixed units is constant (the number of full time employees) and as a Director you want to know how much work your team can produce.  What tends to happen in these scenarios is the queue of work is constant and the duration flexes – you end up telling the poor person at the end of the priority list that their project won’t get done until next year.

In this case, setting Fixed Units would allow you to lock in the resource pool based on the size of your department and then adjust the work to calculate the resulting schedule.  Based on the schedule, you would then be able to tell your stakeholders how many projects can be done in the coming year.

I hope that provides some guidance on how to use this key function in Microsoft Project – I have found even very senior Project Managers do not fundamentally understand how Duration, Effort and Units work together and how to model them in Microsoft Project.  If you understand the conceptual framework and the rules that Microsoft Project uses, you will find that there are less errors in your plan, less confusion and less tearing your hair out when you find Project adjusts your numbers in ways you didn’t intend.

Best Practices for Implementing a Learning Management System

I have just co-written a white paper that is now available through Brandon Hall.

Here is the description of the paper - click the link if you would like to purchase it or stay tuned to my blog for further ideas and writings.

Description

Imagine you've been given the job of researching and finding a suitable learning management system (LMS) for your company. Where do you start?

Everyone knows that selecting the wrong LMS can have terrible financial repercussions and hurt the quality of your learning initiatives. What is often forgotten, though, is that selecting the RIGHT learning management system but implementing it poorly can be equally painful.

This report, written by Gary Woodill, Ed.D., director of Research and Analysis at Brandon Hall Research; David Fell, vice president of Business Development at Operitel Corporation; and Christopher Woodill, Vice President, Solutions and Strategy at Navantis Corporation, is the first in a four-part series on the process of implementing an enterprise LMS.

A typical LMS can take months, if not a year or more, to implement and can cost hundreds of thousands of dollars. Getting it right is critical; getting it wrong can be a problem for both you and your business. Essentially, the process involves four stages:

Stage 1: Planning and Evaluating Business Needs for an Enterprise LMS
Stage 2: Purchasing an Enterprise LMS
Stage 3: Implementing the Selected LMS
Stage 4: Maintaining, Supporting, Operating, and Governing an LMS

This report focuses on Stage 1 and addresses the following:

• Developing a business case for investing in a learning management system
• Considering alternatives to an LMS
• Articulating a vision and scope for the entire project, resulting in developing a “project charter”
• Developing an implementation strategy and project management plan that includes presenting the business case, assessing the LMS's impact on the organization, and changing management strategy
• Developing the communications and marketing plan for the project
  Identifying all stakeholders for an enterprise LMS
• Conducting a requirements gathering exercise, including developing “use cases” for each business unit and group of stakeholders
  

If you have thoroughly carried out the above suggestions, then you are ready to prepare and send out an RFP, investigate products and vendors, and move toward purchasing a learning management system. It’s also important to note that getting this first stage right provides a firm foundation for success in all the later stages.

Breaking the Law of Triple Constraints

In classical project management methodology, there is a concept called the Law of Triple Constraints:




The law states that as two of the constraints are changed, there must be an equal change on the third constraint while still maintaining the same level of quality.

For example, if scope is increased and schedule decreased, this MUST have an impact on the number of resources required. If resources are decreased, this MUST have an impact on either scope decreasing or schedule increasing.

However, in practice, this law is not really a law at all, or rather it is based on idealistic assumptions.

These assumptions are as follows:

1. The process for running the project has been 100% optimized.

2. The process for running the project is 100% known and not subject to any possible innovation to improve the picture.

3. Talent on the project is not changeable or all talent is the same.

4. The amount of management is precisely what is required to manage the project.


The reality is that in most projects these assumptions are simply not true. In addition, this model promotes a mechanistic, deterministic approach to managing projects that lacks an hope for innovation, efficiency or reduction in management.

Here are ways you as a stakeholder or project manager can "break" the Law of Triple Constraints without sacrificing quality:

1. Re-examine your estimates and make sure they are not overly padded. Some contingency is always required in order to handle unexpected events. However, on a $1 million project, the difference between 10% contingency and 30% contingency is $200K - is it really necessary?

2. Challenge the team to be innovative about process, documentation, testing, builds, etc. There are better ways to doing any project - no team is 100% optimized. I've seen simple changes such as using automated unit testing that makes massive differences in effort and actually improves quality. Depending on the type of project, there is innovation to be had.

3. Do you really need to build something or can it be bought?

4. Be ruthless about gold-plating on all sides. Developers, stakeholders, creative directors, etc. all like to add changes, rounds of revisions, additional documents, new features, etc. and that extra 10-20% makes a difference over the course of a large project.

5. Improve communication and lower documentation overhead. For every 300 page use case document you have to write, edit, review and then update make sure they are necessary artifacts and they have value. I was on a project once where the wire frame document cost $100K to produce!

6. Make sure you have the right talent for the job. For hard problems, you may think that having your junior flash developer be your technical architect will save you some money but in my experience the opposite is true - get the best talent you can possibly afford because they pay for themselves in much higher value than the additional cost in salary. For easy jobs, don't take your technical architect and make him your excel macro monkey - it will frustrate him/her and is a waste of their talent.

7. Get Creative! On every project, there are ways to innovate. It may be in the implementation of a particular module. It may be that you re-examine the problem you're solving and come up with something more elegant than when you originally built your plan.

8. Make your team entrepreneurial. Encourage open communication, risk taking, fast decision making, and low document overhead. Have the right level of process and no more than necessary. Give everyone ownership in the project and let them understand the big picture.

9. A simple tip: make sure your team members know deadlines! It sounds really dumb, but I have noticed a big difference in teams where they can see the entire plan and understand the context of deadlines than if a person is just handed a task piecemeal and told to complete it blind.

I've seen project plans that are bloated and I have seen some that are way too lean. Starting with bloat and cutting down I find is easier to manage than starting lean and trying to increase to handle the bare minimum requirements. Start with a robust, conservative and full process plan and then take a good look at it and see if there are some trimmings to be had.

One final note - this is not a panacea and in my experience, you can achieve a savings of somewhere between 0-20%. Don't expect that you can cut your project timeline in half. However, on a $1 million dollar project that's still $100-200K and on a 6 month timeline that's still a month of time saved.

As a project manager, you can choose what you do in terms of managing stakeholders' expectations. Typically, I use a conservative estimate to start and then I try to get innovative once I'm executing. If the risks of being creative and entrepreneurial pay off, then I look like a rock star with a project ahead of schedule, a happy team and satisfied customers.

But if you are a project manager who simply adheres to a conservative approach and obeys the Law of Triple Constraints like dogma, then you will be missing opportunities to innovate!

Software Development Metaphors

There are lots of discussions on Software Development "methodologies". They are codified sets of practices on how to do software development "correctly". When you get down to the root of each of these methodologies, the root of all of them is a metaphor. Before you adopt a methodology such as XP, Scrum, RUP, Software Factory, etc. you should really ask yourself what metaphor you believe your particular software development practices fit into and what metaphors fit your particular organization's culture. If you start there instead of at the "here is my fancy new toolbox of processes" then adoption will be higher.

So here is a list of popular metaphors used to explain the practice of creating software...

The Traditional Software Development Metaphors

Software Development as Factory

• Heavy emphasis on frameworks (assembly line) and components (widgets)
• Use in large scale development projects (hundreds of developers) or highly distributed projects (outsourced)
• Highly centralized control of processes, tools, etc.

Software Development as Engineering

• Heavy focus on estimation techniques
• Fixes made in planning are less expensive than after “construction” has started.
• Highest project management priority is being “in control”.
• Software development as a science, e.g. objective, measurable.
• Belief that Software Development is an immature or imprecise version of engineering.

Software Development as Model/Architecture

• Architect as “GOD”
• Code is simply implementation of a model
• If the software doesn’t work, either the model is wrong or the code doesn’t implement the model properly.
• Tooling can automatically generate application from the model.
• Software models a business, a process, etc. in design. Goal of software is to accurately reflect real life processes.
• Need specialized modeling languages, expertise, and tools

Software Development as Workflow/Process

• Projects as repeatable processes.
• Workflow is defined up front, and people are compartmentalized.
• Emphasis on distribution, encapsulation and hand-off.
• Project managers are process champions – they make sure the rules are followed.

These metaphors have formed the bedrock of software development. They represent the traditional way of viewing software development as well as project management in general. They have enabled a whole toolbox of techniques, tools and templates for managing projects and software development.

The Radical Software Development Metaphors

These metaphors have become in vogue thanks to various agile methodologies, reactions against the traditional view of software and frankly a lot of failures for the traditional metaphors to come to grips with the complexities of creating software.

Software Development as Craft/Voodoo/Martial Art

• Focus on simplicity, elegance, and craftsmanship
• Toolbox approach
• Apprentice / Master / Guru model
• Software is highly dependent on people
• Software “Design” provides guide to picking solutions

Software Development as Game Playing

• Games are processes without the prescription
• Games can be open or closed, cooperative or competitive
• Rules of the game are enforced, but outcome is unknown
• Games also include collaborative activities such as sports, playing music, dance, etc.

Software Development as Book Writing/Composition/Poetry

• Iteration, drafts, reviews, etc.
• Focus on creativity within an established structure.
• Objective is known, but product is not well defined.
• Challenges in forcing creative process into rigid scope, time lines and budget are recognized.

Software Development as Learning/Experiment/Invention

• Modeling in software is about learning
• Documentation, requirements gathering is a means to collective learning
• Focus on establishment of common language
• Prototyping, experiment, measuring as a way to learn

Which one fits your culture, your organization needs, and your skill set? If you're a start-up company, then the software factory metaphor might not be the best fit. However, if you're building printer drivers with third party outsourcers in India, then perhaps it is the right model.

If you start with basic metaphors, the toolbox and methodologies such as RUP, XP, Scrum, Waterfall, etc. start to make more sense - they're expressions of the underlying metaphor. In addition, if you want to evangelize a new software development methodology (for example, those who are trying to evangelize the use of XP in a traditional RUP organization) starting with a discussion around metaphors and basic understanding of software development might help the discussion, especially with non-technical users.

One last suggestion - this discussion is a great interview topic for Project Managers. If you want to hire an "Agile" PM, then start the interview with the list of metaphors and ask them which one they believe fits their style of working. If they pick one metaphor, then get them to explain how their PM toolbox (GANTT charts, risk matrices, status reports, etc.) fit into the metaphor. The traditional toolbox can be used in an agile context if the underlying metaphor is right - there are ways to use MS Project even if you believe that Software Development is more like writing a book then building a bridge.

Project Planning in an Agile Project

Tate Stuntz has an interesting post on his blog arguing that Project Plans are obsolete and hard to maintain when doing Agile projects. In my experience on agile projects, project planning and Gantt chart making definitely has to change, but there are still ways I think you can make MS Project and Gantt charts work for you in an agile context. Here are my recommendations based on my experience:

• Learn to use MS Project efficiently (see my previous post for recommendations). I've seen PM's take 2 weeks to build a project plan - if this is you then trying to work this way in a 2 week iteration cycle means you're not moving fast enough. You have to be at the point where you could re-boot your project plan in a matter of hours so that you can adjust quickly.
• Use MS Project for planning and not for tracking. If you're working with short iteration cycles, you'll see improved tracking by simply management by walking around. In addition, measuring project velocity is more valuable than percentage complete since in an Agile project the finish line is not always defined.
• Use a project plan for iteration planning at a macro-level and not for iteration tracking within an iteration cycle. What I like doing is maintaining a project plan with a simple list of user stories in each 2 week iteration. That allows me to track dependencies between user stories pretty easily. At review time at the end of an iteration, we discuss the next iteration with our stakeholders and reset expectations by re-forecasting the plan (which takes no more than an hour of work). That gives stakeholders a good understanding of what we currently see as in and out of scope and when features may be coming up. This is highly valuable and I find is critical for buy in for stakeholders - if the response from the team is simply, "we can only see to the end of the next iteration cycle" this tends to make business users very nervous.
• If you need pretty Gantt charts, one of my favourite methods is to use Visio - it provides pretty Gantt charts for presentations without the fuss of Project.
• I tend to use the whole team as a big pool for planning iterations. This gets you out of the micro-detail of having to assign one user story to one person, another user story to another person and so on. If I have 4-5 developers on a team, that gives me 70 hours x 4-5 developers for a total iteration budget of 280-350 hours. I can then do a good estimate of each user story that includes planning, development and QA with the team. We simply add up a bunch of these stories into the budget and that becomes the iteration. The way to do this in MS Project is to take your steps and instead of assigning individuals assigned to each task and running them in parallel try simply taking a generic role of "developer" and assigning them at 500% to every task in sequence. You can then tell how much time you're going to spend across the entire team without having to fuss with all the micro-dependencies.
• For preliminary planning, use low-tech Gantt chart tools such as whiteboards, post-it notes, etc. I can create a Gantt chart without MS Project using a white board, some markers and post-it notes. This works great without the overhead of the tooling getting in the way. If you want to preserve it, simply take a digital photo of it and store the picture.

I think if you follow some of these techniques as a Project Manager, you can still sleep at night without feeling completely out of control and yet move faster and leaner. In addition, you can use project planning to help sell the concept of Agile to stakeholders who aren't as comfortable with the XP style of development and give them the comfort of a traditional project plan without locking yourself into the traditional bureaucratic approach to Project Management.

Low Tech Approaches to Requirements - Part 3

For those who missed Parts 1 and 2, see the following previous posts:

• Part 1: Different Techniques on using non-tech tools for requirements gathering
• Part 2: Using existing tech tools in simpler ways to speed up requirements gathering.

One of my staff sent me this image today and I thought it was a great example of how to use low-tech approaches to conversations. He simply took a screen shot of a screen, threw it into MS Paint and then started making changes with the developer beside him.

Between them in 5-10 minutes they had a "language" for what the marks on the screen mean:

• Red lines through something mean to get rid of it
• A box with text means to insert a new column
• A line on a checkbox means that on checking it something will happen
• etc.

So instead of using UML, fancy wireframes, or some bureacractic documentation process, try simply taking a screen capture and throwing it into Paint!

Test Driven Development When Writing New Code

I have been doing TDD for several years now, and I can still not get around the recommendation to test first to the point where it breaks the code, write enough code to pass the test, and then go to the next test. In my experience this tends to work with mature code bases where there is a chunk of existing code that is being changed. However, I'm not sure this approach works for new applications that are being built from scratch. In my experience, a less purist approach seems to work for me:

• Write enough code to get something at least working minimally. If you think of a use case, I'm not sure there is much point in writing gobs of test cases before you even have a primary path through the use case. The XP methodology talks about an architectural or design spike, but in my experience there is also a coding spike. For example, it might be the first iteration that instead of writing code + tests we just write as much code as we can to push through the primary path as widely as possible instead of trying to be exhaustive in our testing.
  
• I use at least a basic unit test in NUnit as an entry point in all code debugging. That enforces the practice of having tests but also provides a useful way to gain entry into the code without web pages, windows forms, or a global main method. Using TestDriven.NET, you can simply right-click a test and run it right in studio using the debugger, NUnit, NCover, etc. and I find this higly efficient when writing new code.
  
• There does seem to be a drop off point where writing more and more tests provides less value, as in any testing effort. I'm seen some overly puritanical approaches to TDD where it was insisted that every boundary condition was to be coded up as a unit test no matter how unlikely the scenario or risk. In my experience there is a point where coding these scenarios is not worth the benefit of the test. In addition, I have found that in some cases it is still easier and better to manually test something than to try and code it up as a test.
  
• I definately like the idea of using build scripts and NUnit tests when making modifications to code. However, In my experience the tests actually don't change as much as the underlying code. In some cases there are new requirements but in many cases they are implementation changes. As long as the existing tests are still green after the change, then no new tests are required.
  
• There seems to be a trade-off between quick progress and the feeling of "being on a roll" and the pace of TDD which tends to be plodding but regular. Again, I think a less purist approach is best - at some points you feel your creative juices flowing and you want to plow through 2-3 pages of code in one go without writing exhaustive unit tests for each little method. Other times if you're being more cautious you want to test the living hell out of every line of code. As a mature developer, you have to feel the right pattern depending on the code you're writing.
  
• Lastly, I think its critical that at a minimum unit tests are written before code is checked into source control. That way if you have continuous integration the unit tests will run on every build. It seems also just a courtesy - you might have insight on why you left out some tests but your team mates might not. So before checking in code make sure there are tests to go with it. I find also that the unit tests are really a good description in code of the requirements so for new code its really helpful to have them as a guide.
  

For code changes in a larger mature application, I like the traditional TDD process of making new tests so that they fail, writing code to fix the tests and then regression. But for coding applications from scratch or starting a new major code project, I find a looser style tends to produce better results.

So with any agile technique, don't get to ideological about the approach - in my experience, TDD is best used as an approach and not a rigid perscription.

Getting to the Finish Line in an Agile Project

One of the great potentials of Agile software development is flexibility in changing requirements. We currently use agile methodologies and have scheduled 2 week iterations. We have show and tells with stakeholders every two weeks where we show them where things are at and gather new user stories, functionality changes and other feedback to plan for the next iteration.

One of the challenges we have found with this approach is that the project quickly turns into perpetual development. One of the advantages of a traditional waterfall model is a solid arc in development and a very specific deliverable - you have a good definition of when you're done. In an environment where the requirements evolve, the time lines are fluid and the stakeholders are not that experienced at software projects we are finding that this means that the project never seems to end! Every two week iteration, stakeholders simply pile on new requirements and the launch date drifts away.

In a consulting environment, this isn't such a bad thing if you're on a time and materials engagement - the client simply gets to spend their money as long as they want. But in an internal development team, this poses a challenge because most stakeholders aren't really aware of how much money they are spending and they simply keep monopolizing the team. In the meantime, there are other projects or priorities queueing up in the background.

Based on what we have found works, here are some practical recommendations on how to combat this problem:

• Establish clear business objectives and as many solid functional requirements as possible. There is a happy medium between XP style iterative programming and a rigid waterfall model. Try to put some acceptance criteria that can be measured so that the entire team has a common understanding of the target.
• Remember the law of triple constraints - of cost, resources, and time changing any of these impacts the others. Make sure that stakeholders are aware of the real cost (even if it is an internal cost) through an internal budgeting model. In our organization, we have a shared cost model in IT but we can allocated the shared cost to any department we choose. In cases where we see departments monopolizing our time we can allocate more cost to them. This gives internal stakeholders an incentive to prioritize and conserve resources.
• Make stakeholders compete with each other. This is pure politics but it works. The easiest way to stop a project is to simply tell another stakeholder that they're waiting in the queue behind someone else. There will be a pretty quick meeting between stakeholders where one will start to put a lot of pressure on the other to get their project done quickly or to get out of line altogether.
• Time box and resource constraint the project explicitly. We do this quite a bit with reporting needs which seem to continually evolve ad nauseum. When we start these types of projects, we establish a budget of 2-3 iterations and that's the budget. The requirements can evolve but there continues to be pressure on the stakeholder to get it right the first time or else lose their window.
• Always have a phased approach with Phase 2 and 3 already planned in Phase 1. This gives the stakeholder the ability to still feel they're going to get a change at some point but perhaps can live with launching without it.
• Be vigilant and communicate often about what's currently in and out of scope. I'm not sure whether stakeholders intentionally play dumb or whether people simply don't hear bad news but I've experienced several times the case where three meetings in a row we hear questions about a feature that we've already ruled out of scope and there is genuine surprise from the stakeholder that they're not getting a particular feature even if its been already discussed, documented, etc.
• Have really strong leaders in QA. QA Leads, especially in the latter stages of projects, become crucial at communicating and organizing priorities. A great QA Lead can manage stakeholders on a daily bug review meeting and can handle the constant re-negotiation of last minute feature requests, low priority bug fixes, etc. and keep the process moving towards launch. If the project loses velocity during the stage it opens the door to ever increasing scope change. If the project has high velocity then everyone on the team feels like they better prioritize because time is running out and the project is going to launch without them. This helps crystallize priorities and puts good pressure on stakeholders to commit to the minimum work required to launch.

I've been in projects where we sat at 90% for 5 months because we kept stalling as we closed in on the finish line. In addition, I've been on projects with internal teams where the stakeholders simply got used to having a software team at their disposal week after week and their was never any pressure to launch anything or to stop working.

As a project manager, your goal is to launch - 90% complete is really 0% complete especially if it's still just running in development or still buggy in test.

Low Tech Approaches to Powerpoint Presentations

Take a look at these videos as a low tech presentation format. Think about how you can use these techniques for selling ideas, explaining technical concepts, brainstorming, etc. For more ideas on low-tech requirements gathering, see my previous post as well.

Implementing an Agile Change Control Process

What is Change Control?

Change Control traditionally is a project management process for managing change. The typical method for managing change in a classic PMP project is a Change Control form that is filled out containing the scope of the change, impact to the project, etc. This is then approved and incorporated into the master project plan, charter, etc.



In addition, Change Control processes are used by operations departments to manage the deployment and promotion of code from one environment to another. The Change Control Form provides the documentation for an operations team to deploy, operate and monitor the change.

Change Control and Agile

This traditional view of Change Control is at odds with Agile methodologies for the following reasons:

1. Change is viewed as a non-typical event, e.g. the project was running smoothly until someone threw a change into the project. Agile projects by definition are based on the assumption that changes are typical events and aren't special.

2. Change requests are simply Waterfall designs in miniature. Requirements for the change must be documented up front and analyzed. Stakeholders must approve of changes before they are made with the assumption that requirements, scope, risk, and design can be formally documented ahead of making a code change.

3. Traditional Change Control processes are document heavy. The process is designed as much to capture and document change as it is to make effective decisions. Change control forms are kept around forever with dates and identifiers so that someone could find out who approved a change. In many cases, these are also printed out, resulting in very large binders of paper with signatures for every change.

4. In an agile project, one of the objectives is to flatten the team and reduce hierarchies so that people can more effectively communicate. However, traditional change control processes require specialized knowledge, special powers of approval and a hierarchical command and control structure. Project Managers are usually the writers of change control forms, but then they must get approval from "Stakeholders" who will bless the change.

Here is a good example of a traditional Change Control process - have a look at Bell South's Change Control Process Guide. At 120 pages, it is a great example of how bloated a large formal change control process can get when Project Managers are working in a bureaucratic environment. Just managing the process documentation alone takes a massive investment - just look at the 20 pages of version numbers of this document and you'll see that someone's full-time job must be simply keeping the guide up to date!

Change Control isn't a bad thing - the original objectives behind formal Change Control are actually in line with the objectives of agile methodologies:

1. Define change and anticipate change early instead of leaving it to the end.
2. Providing a process for incorporating change during development of a project.
3. Communicate scope, risks and impacts of a change.
4. Provide the appropriate review and approval process to authorize a change.

It isn't that change control is bad - it's that the evolution of formal project methodologies has led to very bureaucratic, documentation heavy processes. In addition, keep in mind that most of these processes were invented before the incorporation of digital collaboration tools such as email, Wikis, sharepoint, JIRA, Word, etc. and so the typical change control process has artifacts from a non-digital era.

Implementing an Agile Change Control Process

Change Control can be used effectively in an Agile environment if it is sufficiently light weight, non-bureaucratic and collaborative. Here are my recommendations based on what I have seen work effectively on Agile and non-Agile projects:

1. Use an agile methodology such as XP, Crystal, Scrum, etc. that has change management built into its fundamental process. In Scrum, for example, all work is effectively a change and is logged as a "change request" in a work backlog. In XP the changes are logged as User Stories. Iterations allow for changes to happen on a regular basis - they're not special change events.

2. Use a generic task tracking system such as JIRA to log any change. In JIRA, you don't need a separate "bug tracking" system that is different than your change tracking system. In addition, you can take a change all the way from requirements to deployment without re-entering information. You could do the same thing with low tech tools such as Excel or Word simply by having a work log that is updated regularly.

3. If you have specific legal or regulatory reasons to track changes then try to understand the specific minimum requirements. I've worked in a government environment for example where all changes needed to be documented so that they could be audited. But the level of detail that was incorporated into each Change Control form became ridiculous - an auditor probably doesn't really need to see a change in an individual SQL script, a deployment checklist that includes changing ODBC connection strings, etc.!

4. Eliminate as many approvals as possible. We had a change control form that had 10 signatures on it - I was one of them! I used to get these forms across my desk documenting some change to an application that I had never even seen, had no idea how to measure the risk of the change and yet I was expected to "approve" it. Even worse, the signature had to be on paper so there was a constant stream of people running around with pieces of paper trying to find me to get my signature. Eliminate all this process and identify the minimum number of people who need to be involved in any change.

5. If you're going to have a Change Control Form/Process, keep in as light as possible. Your form should be no more than 2 pages and should be as automated as possible. We currently use JIRA to automate all our tickets. In previous environments, we've used Outlook forms. I've also seen this done use Word with Macros enabled to provide drop downs, automatic fill-in, etc. Keep your process light as well - if you need 2 hours of training to teach someone how to make a code change, then something is wrong!

6. Keep Operations teams involved from day one. One of the primary reasons why change control forms are deployed is because Operations teams get tired of having code dumped on them without documentation or involvement. The typical solution is to put in a gate keeping process to keep the developers from deploying something unsafe to production. This is a legitimate role, but change control processes typically provide artificial security - simply because a developer has filled in the proper form doesn't mean their code works as advertised. Instead, have an Operations Lead that is an integral part of the project from day one who will have a specific understanding of the project and create the right level of documentation, deployment guides, test cases, etc. and be testing these along the way. This is far more effective than a large form being written at the end of the cycle.

7. Keep stakeholders involved throughout the project. The reason why Change Control forms need to be so heavily documented is because the key stakeholders have not been involved all along the way. If stakeholders are seeing working software using Show and Tell techniques, then Change Control simply becomes regular involvement in the project.

8. Use multiple models of communication. Instead of having a single Change Control Form that forces people to write in a specific way, allow for multiple models of communication that could include meetings, power point presentations, white boards, Visio diagrams, etc.

Based on the above principles, here is my current favorite flavour of Change Control:

1. We build our requirements using use case documents that living documents. We currently use Word because its dumb simple and stakeholders can easily open it and change it. We use power point for wire frames and Visio for almost everything else.

2. Revisions of documents get stored in source code control for safe keeping and history. However, we're not dogmatic about it and in my experience the value of these minor revisions is usually not significant - most stakeholders want to see the current version. We keep them in our repository so that everything is stored together and document revisions are tied to code revisions.

3. We have iterations every 2 weeks that include review meetings with the entire team including stakeholders. We do a show and tell of all working code and we use the meeting to prioritize and change. We typically do this by opening up documents on the spot, but sometimes we use pen and paper and transcribe the changes right after the meeting.

4. We use JIRA for day to day tracking of tasks. We treat all changes, bugs, feature requests and tickets the same way. We have a very simple work flow that moves all tasks from open to resolved to closed. Our list of changes can be pulled directly from JIRA as a list of changes. The list of outstanding bugs can be also pulled at any time so we don't need a specific final bug review meeting - we will have been reviewing them on a daily basis.

5. When we're getting close to deployment, we use white board based checklists to capture the minute details (e.g. make sure the ODBC driver is configured properly) that need to be done to move to production. We check these off by simply crossing them off or wiping them from the list. We have 15-20 minute stand-up meetings that includes the Operations Lead so that we're communicating effectively with Operations and they know exactly where things are at as we move into production.

6. Just before doing a deployment to production, I have a meeting with executive stakeholders with a very high level presentation in power point. It presents the current status, any risks that they need to understand, confidence in going, and high level operations plan. Executives typically don't care about whether the SQL is right - they want to know that the team has confidence that it can deploy safely, has followed the appropriate testing processes and that the team is on standby with a contingency plan in case things go wrong.

There are lots of variations to this process and many different tool combinations. You can scale the process up or down depending on the size and formality of the project. In addition, if you're working in a specific regulatory context you may need to be producing more formal documents, approvals, audit trails, etc. My suggestion is always prioritize these below communication and if you need to do this for regulatory purposes then do so but keep the work as minimized as possible. Never substitute change control processes for good communication, team collaboration, stakeholder involvement, etc. In addition, remember that Change Control is a means and not an end - working software is the objective and should be focus for the team.

Communication of Software Risks

One of the interesting challenges in managing a project is estimating technical risk.

Here is an example of a classic technology risk scenario:

The development team is building an online transaction system that sends orders from an e-commerce system to a warehouse. The e-commerce system is internal, the warehouse is external. The warehouse works on an AS400 system and no one on the team has ever worked with AS400 platforms before. There is a defined web services layer between the two systems which should hopefully hide the workings of the AS400 system behind the layer.

This is a pretty typical high level description of requirements from a manager, a request for proposal, or an email.

Most developers look at this and start analyzing all the things that could go wrong...there are dozens of risks just in this one paragraph.

A project manager might realize that there are some risks involved and if the PM has a technical background might be starting to ask some risk based questions that show some understanding of the potential problems. The worst case scenario is a non-technical PM who thinks that this project is the equivalent of ordering pizza from Domino's - you simply call and expect the order delivered by the guaranteed delivery window.

Let's assume that the entire team is on the ball, everyone's working together and the team comes together to review the project plan. A risk matrix gets created and the team comes up with the following risks:

Risk: Web Service might not work
Probability: Medium
Impact: High

Risk: AS400 might have performance problems
Probability: Medium
Impact: Medium

Risk: Transactions might not work across the two distributed systems.
Probably: High
Impact: Low/Medium

and so on....

This is the critical point where there is a massive communication gap between what a typical PM thinks a risk impact is and what a developer think of a risk impact.

A PM may think, "Well we have some risks so we should allocated some contingency in the budget. This is a high risk project, so we'll add in 30% contingency to our estimate and a month onto the time line."

A Developer may think: "If this server cannot move data fast enough, we're dead in the water. It won't matter how much time or money you throw at it because short of hauling out the entire AS400 out the warehouse we're toast."

Big difference in risk!

I've seen projects where there were mature team members and did all the traditional risk analysis that is recommended on software projects. But the project still failed because there were fundamental differences in assumptions in what "High Risk" actually meant to cost, time line and project success.

Here are some common reasons why there are differences in assumptions around risks.

1. Team members don't all have the same assumptions on impact of a risk. For example, a task is estimated at 3 days but the impact of the risk is "High". So what does that mean to the estimate? Add 10%? Add 50%? What about 10X? In my experience, project managers in particular do not understand the sheer magnitude of software risks - they'll see a risk as "High" and put in contingency of an additional 30% and think they're good to go.

A 10X risk impact is not unheard of - I've seen it myself on many projects. We had one project where one web service call was supposed to take 3 days and took 30 days because of technical complications.

2. There are some risks that result in project failure because in some cases requirements are not variable. For example, financial data cannot be more or less correct - its either right or its wrong. So getting to 80% right isn't really valuable - if you cannot hit the 100% mark then your software project fails. So if you have a risk that the data isn't going to be right then it isn't so much that your project went over budget or took too long to deliver - its a total failure because it cannot meet the basic requirements. Same thing with external software dependencies - for example we had a case where we were integrating with a web services framework and there was a bug in one of the supplied web services from the vendor. It wasn't a matter of "let's just find a work around" - the project was effectively dead in the water until that bug was solved.

Project managers tend to be solution oriented and optimistic, so while they like the idea of contingency, they tend to shy away from the concept that a risk might actually kill their project with no way to get around it.

3. The "I don't know" estimate will get quantified too early on in the process or not be listened to at all. If your team is saying, "I don't know" as a project manager, what is your approach? Many PMs are forced into providing estimates too early by management, so they simply fudge the "I don't know" into a contingency or pad the estimate. They think that by taking the developer's estimate and doubling it they've been given themselves a massive breathing space to worry about the problem later.

The cone of uncertainty on typical projects is a lot bigger than most PMs realize - Steve McConnell's work on estimation pegs the variance at 1600%!



If the team doesn't have a common understanding of how to quantify the impact of risks, then everyone can be communicating using a traditional risk process but the shared understanding of the impact of any risk will tend to be different.

Here are some recommendations for Project Managers for creating an improved risk communication culture:

1. Vary the risk based on expected uncertainty level and the phase of the project. For example, if you're in the planning phase the expected uncertainty level is high. If someone on the team says, "Well we don't really know how that's going to work but we have a plan" that's probably OK. If you hear the same thing in the middle of QA, then you should be very concerned and adjust accordingly.

2. Have the team translated risks from labels ("High", "Medium", "Low") to numbers where possible. In addition, don't assume that one set of labels means the same across the project. For example, a "High Risk" HTML issue might be something very different than a "High Risk" web services integration issue or performance issue.

3. Identify the requirements that are absolute and unmovable and pay particular attention to risks that are around them. For example, in some cases performance is an absolute requirement (e.g. it must serve 30 pages per second) and sometimes it isn't (it must be "fast"). If your requirements are absolute then any risk that hits those requirements will not just cause a delay, an increase in cost, etc. - it will kill your project.

4. Pay close attention to areas of the project where there is limited flexibility or options. Compare the flexibility of a creative front end vs. a bought software system. If someone doesn't like the the front-end, you can rebuild it, change it, etc. It might cost more, create a time impact, etc. but you've got lots of flexibility for change. If you buy Microsoft Content Management Server and it has a bug in it your options are pretty limited.

5. "I don't know" must be a viable option in any discussion. In addition, the response to "I don't know" should be to go find out - be careful about arbitrary padding of estimates simply to factor it into your plan.

6. Pay close attention to body language, talent and historical experience. Relationships matter in software teams and a team that has worked together before has the advantage that the PM starts to recognize the subtleties of individual communication styles and to understand how each person reacts to different questions or risks. Is John an optimist or a pessimist? When someone says, "I don't know" are they being cagey or honest? Teams who have worked together start to intuitive find out these non-verbal cues.

7. Review risks on a regular basis so that you can refine your strategies to mitigate them.

Hopefully that helps you in creating a more pro-active risk based approach and to be aware that just because people the team are calling somet "high risk" they may not actually mean the same thing.

Developer Weasel Words

As a development manager or project manager, you here a lot of weasel words and excuses from your staff or from external consultants who are trying to hose you into believing things are better than they are. In many cases, developers use these phrases to even convince themselves that things are better than they are, resulting in chronic late delivery and poor quality.

So beware the following phrases from your teams:

• It should work: this usually means that it doesn't. It also means that it was probably not tested properly as the result is current undetermined. The word "should" should be taken out every developer's vocabulary - it either does or it doesn't.
• I just need: beware of that word "just". Its a belittling word meant to make things smaller than they are. Just take the phrase "I just need to write this component" to be "I need to write this component" and already the magnitude of the work involved grows. Developers tend to be chronic under-estimators and the use of the word "just" is a sign of that mentality.
• Almost done: this is also a weasel word. When a developer tells you things are "almost done" ask for the specific tasks that are left over immediately. In addition, keep in mind that projects do not progress linearly - the last 10% is always about 40-50% of the work of the total project. I've seen projects that are chronically late be "almost done" for 3 months.
• It was tested: this also usually means it that wasn't tested properly. Ask for a test plan and the specific tests that were done. If the developer cannot produce these with sufficient evidence that PROVES that it was tested, then it wasn't tested.
• It must be an environment/configuration/deployment problem: this may be actually true, but it usually points to a larger stability problem. If you cannot build and deploy reliably then why would you have confidence that the code works?
• If things go smoothly: this I hear a lot, e.g. if we don't hit any snags then we can be done by Friday. Guess what - you're likelihood of hitting a "snag" by next Friday is probably high and given the lack of risk based management, the team has probably got no mitigation or contingency strategy. Then next week, you'll hear the next phrase in our list, "Yes, it could have been done if it weren't for that Snag we had".
• Yes, but, as in "Yes it can be done, but": this means it cannot be done. Tell your staff to just come clean and say, "No it cannot be done". Another variant on this is, "Yes it could have been done, if it weren't for marketing, requirements, technical risk, etc." This simply shows that your developers work in an idealistic world where things never go wrong.
• We'll make up the time at the end: if you're already late by the end of requirements, you're likely going to be even later by the end if you simply keep going on the same track. In my experience, teams don't dramatically faster as they hit their stride. Even if there is some efficiency, its nowhere enough to make up for lost time.
• I've got it done, but I need to build a few more components for you to be able to see it: then its not done! Encourage show and tells, code reviews, unit tests, etc. so that code is visible as soon as possible. Use slicing models so that you can see pieces of the application in weeks, not months. In addition, code that isn't checked in should never be counted - that means that someone cannot build it sufficiently to share it. It only counts if you can verify it. Ideally, its not "done" unless there are sufficient unit tests, a build script, and a document that someone walking into the code repository could check out the project run a build and have all the unit tests pass. Then the code is done - anything less is mythical.
• I've got it done - I just need to integrate it: The word "Integrate" is a big weasel word. Think of a web service that adds two numbers together. The algorithm is one line of code. But the integration work is huge. In addition, integration usually means the first time that disparate teams are bringing code together which is always cause for issues. Don't under-estimate the integration, especially in today's world of distributing computing, web services, etc.
• It Worked on my Machine!: programmers use this excuse to downplay a bug. The reality is actually the opposite - it means that you have an intermittent bug which is by far the worst kind of bug to have in your application. You want bugs to fail quickly and consistently - any variant such as "That's Weird", "That didn't happen yesterday", "That must be a data problem", etc. is admitting you have a bug that cannot be easily duplicated.

My recommendations to reduce the amount of excuse making from your team:

• Encourage a culture of honesty and team work: You get these excuses when developers are hiding things, and sometimes this is because you've created a culture that encourages hiding because you don't want an honest answer.
• Be ruthless with your quality and talent standards: don't excuse poor talent, bad management or chronic late delivery. If you create a culture where talent isn't rewarded the bar isn't kept high then you'll be excusing the team to continually strive for excellence.
• Expect more than just code: measure performance based on estimation, quality, delivery and team work as well as pure code quality. If you have a developer who produces great code but cannot deliver on time then that's not a great developer.
• Increase visibility and shrink delivery cycles: if you have to show your work on a constant basis and deliver on 2 week iteration cycles, your excuses tend to go away. You either deliver or you get found out pretty quickly. Use show and tells, code reviews and continuous integration to see what people are doing on a constant basis.
• Don't give half credit for 50% done - its either done or not done: If your tasks cannot be managed this way, then you should split up your tasks until you can work this way.
• Establish what "Done" really means: for example, at a minimum "Done" should mean checked into source code control and able to build into the current branch. If you're doing Test Driven Development, it should also mean all tests run successfully. If you have specific performance criteria, then its not "Done" until the performance tests pass.
• Use counting techniques to measure wherever possible: this is a great suggestion from McConnell's book on estimation. The more you can count in units, the more accurate you estimation. So if you can count the number of pages, web services, objects, databases, tables, stored procedures, tasks, etc. that are left to accomplish then you can measure them more easily than if its a big blob of work. If your requirements aren't well defined enough to count objects, e.g. you don't know how many web pages you're building in your web site, then you're really not in a position to estimate your ship date.
• Don't sucker, manipulate or bully your team: If as a project manager, you resort to traditional management tactics such as playing games, being political, establishing a blame culture, or bullying your team you'll lose your credibility and simply encourage lying. A tortured prisoner will tell you anything you want to hear - the same goes with development teams.

If you have a project that operates in the open, has a culture of honesty and establishes a high performance bar, you'll find that peer pressure as well as some overall guidance will get risks, problems and bugs out in the open. If when you discover these problems people work as a team to fix them instead of blaming each other then every problem solved becomes a victory and not a blame opportunity. You'll get better answers and improved morale on the team as you set clearer performance expectations.

How to be an Effective Stakeholder - Part 2

The Role of the Stakeholder
Part 1 - Introduction

Stakeholders who are effective on projects understand their valuable role. This post articulates what effective Stakeholders bring to the table.

There are a few different types of Stakeholders:

• Direct Customers: if you're lucky, you get end-users as stakeholders. These are great to have because you know that these users represent actual end users who will use the application on a daily basis.
• Domain Owners: some stakeholders are involved in software projects because of their domain expertise. Software developers are good at building software, but they're usually not domain experts as well (although some will claim to be). So if you're building a financial application, its important to have someone on the project who knows the minute rules on accounting. Not only is it important to have general expertise, but it's equally important to have domain experts who know the specifics of the business. There are dozens if not hundreds of hidden business rules in any business and in many cases they are only learned through oral tradition. Domain owners provide this expertise.
• Customer Group Representatives: if you cannot get direct customers or if your user base is large, then you need to have Stakeholders who can represent the needs of the customer. Be careful about this in that it's important that the Stakeholder is an accurate voice for the customer and doesn't have their own agenda.
• Business Representatives: general Stakeholders that represent the actual business. If the business is selling soft drinks, then it's a good idea to have an understanding of how the actual business works and how your application will fit into and support the business of selling soft drinks. In any business, there are also specific experts who own global business areas such as marketing, security, privacy, branding, and customer service. These horizontal service areas are not specific to any vertical project but cross all projects being delivered.

Regardless of the type of Stakeholder, here is what I'm looking for them:

• Decision Making: a Stakeholder's primary responsibility is to make a decision. Should we charge the credit card before we ship the product or after? Should the name field be 100 characters long? Should the colour of the button be purple or blue? There are hundreds of decisions that a software team must make and your role as a Stakeholder is to make the call when asked.
• Approvals: similar to Decision Making, your job as a Stakeholder is to approve documents, decisions, milestones, etc. When I was a Stakeholder on a project with Accenture, they would send me test cases to review. I would simply reply with a single word, "Approved." Especially with external vendors, teams need a formal mechanism for sign-off before they can move forward.
• Opinion and Feedback: in building web sites in particular, there are lots of subjective decisions on what a web site should look like, how it feels, whether it represents the brand, etc. As a stakeholder, your primary job is to have an opinion that can be translated into actions, revisions and improvements. An example of a poor opinion: I saw a graphic design present a screen design to the Creative Director. His opinion was, "I want exactly what you have, but just bigger and bolder!" How is someone supposed to action that opinion? A good opinion is, "I hate that text - its boring and its too long." It's just as subjective but at least you can action it.
• Solicitation of Feedback Amongst the Broader Community: Most Stakeholders represent their department, a user community or a business unit. Key deliverables should be brought back to this broader community for feedback. As a Stakeholder, your job is to help explain, sell the concepts being presented and capture feedback that can be actioned by the team.
• Be Supportive Externally and Demanding Internally: Stakeholders should be evangelists for the team as it helps boost confidence for the team, helps provide buy-in from the great organization, etc. Internally, Stakeholders should be demanding like a good customer. Stakeholders should be keeping the bar high and making sure that the software team feels that they have to meet a high bar for quality and performance.

What frustrates software teams to no end is when Stakeholders are not doing their job. Here are some examples of where Stakeholders drop the ball:

• Showing up to Meetings Unprepared: if you cannot bother to take 15 minutes to read through a technical document that someone spent 2 weeks writing, what does this say about your level of respect for the team?
• Being Late with Approvals or Feedback: when I manage projects, I put review and feedback periods in the project plan. Stakeholders have deadlines for turn around of feedback. Yet time and time again, I've had Stakeholders miss their deadlines with really lame excuses. If you miss your deadlines for reviewing a document, what kind of commitment can you expect for higher risk activities such as building new algorithms or leveraging the latest technologies?
• Abusing the Team: this symptom seems particularly bad with external teams being managed by internal Stakeholders. There must be something in management training that tells middle managers to treat external vendors abusively in order to squeeze them for another 5-10% in performance. Unfortunately for many smaller and less mature vendors, the practice works which only reinforces the practice. However, in my experience a mature software team won't take abuse and understand the difference between having high expectations and simple bullying.
• Poor requirements: if you're supposed to be a Domain Expert, then you need to be able to know your domain. Ideally, your domain is well articulated through existing documents, manuals or practices. If you're supposed to be providing requirements to the software team, then these requirements should be well defined and articulated. Here is an example of poor requirements: we were supposed to build an online store for a client, but no one had given any thought to basic requirements such as tax rules, catalogue structure, content requirements, fulfillment, inventory rules, etc. When we asked basic requirements such as, "What are you current inventory rules?" the answer we got back was, "Well, we don't really have any rules - what do you suggest?". Argh!
• Us and Them: I would highly recommend for Stakeholders to embed themselves into the team as much as possible. The more that Stakeholders are part of the team, the better the communication. If you find yourself viewing yourself as the "customer" and not part of the team, figure out how to get yourself better integrated. Take the team for drinks, start coming to meetings, and support the team by doing your job. When Stakeholders build credibility with the delivery team, it means that when they actually need to put some pressure on them to deliver they'll have credibility to spend instead of simply crying wolf.

I've been on projects as a Stakeholder, a project manager, a technical architect and a sponsor. When the Stakeholder brings their value and integrates highly into the team, it makes a massive difference in the success of a project. If the Stakeholder is flying in and out, using politics and manipulation to get what they want, or being abusive in order to squeeze the team, it tends to put the entire project at risk. As a Stakeholder, I feel responsible for the entire success of the project and I'm not just there to provide input and walk away from the scene. In addition, I don't view software projects as ordering McDonald's whereby you simply throw in your requirements and drive up to the pick-up window to get your order!

How to be an Effective "Stake Holder"

Part 1- Introduction

Every software project has "Stakeholders". There are other terms used for this role such as "Internal Customer", "Steering Committee Member", "Department Head", "Boss", "Sponsor", "Champion", etc. Sometimes stakeholders are formally identified (usually by assigning them to a project directly) but there are also lots of informal stakeholders as well.

While the context for these articles is software development projects, in my experience being an effective Stakeholder is consistent across all projects and the same guidelines apply consistently for other projects as well, e.g. marketing projects, facilities projects, etc. As a Director of Information Technology, I play the role of Stakeholder on some projects and been on the delivery side on other projects. I've worked on projects that are internally delivered as well as worked as an external consultant. So I have seen the Stakeholder role from a number of different angles.

This introductory post gives you an introduction to the role of the Stakeholder and what is expected from you if you have been assigned as one. In future posts, I'll provide some specific techniques, guidelines and suggestions for managing and influencing project teams for Stakeholders.

Your Boss Comes to You with a New Project...

Here are some really bad but unfortunately typical ways that Stakeholders get assigned:

• Your boss has been assigned the role and doesn't want to do it. So he or she delegates it to you. You can continue to delegate down if you choose to do so. I've actually had this happen to the point where the original stakeholder was the VP of Marketing and by the time the project had started a junior copy editor showed up saying, "I was told that I'm to represent marketing on this project"!
• You're in a role of authority and someone on the project thinks you should be consulted. For example, you're the Director of Marketing and someone in HR decides that they want to change the web site to have job postings. You get roped in because you've issued the policy that no one changes the web site without your input. You're now a Stakeholder!
• The project is half way through and someone realizes they need your input. This happens to Operations teams a lot - 80% of the way through development, someone on the team realizes that they need 10 more servers! As the person owning this non-budgeted purchase you're now a Stakeholder!
• You're asked to join or are already part of a committee that regularly meets to discuss general issues. For example, many organizations have branding committees, privacy committees, project review committees, etc. Sometimes projects will make the entire committee a Stakeholder. I had this experience once working on a project building a government web site - there was a permanent "web committee" with 7 members on it who had to meet on every issue and come to consensus on every change. The entire committee was a Stakeholder.

If you find yourself getting labelled as a Stakeholder in any of these scenarios, beware! They are high risk and put increased risk on the project.

Recommendations

Here are some recommendations on when to sign-up to be a Stakeholder.

• Be empowered and qualified to be a stakeholder. The primary role of a Stakeholder is to make decisions and provide input. If the project is expecting a VP level Stakeholder and they get the VP's secretary, they're not getting a stakeholder who is qualified or empowered to make decisions.
• Avoid Stakeholder proxies. Stakeholder proxies are people who show up to all the meetings, collect a lot of notes but then cannot make decisions on their own. If the answer to questions asked of you is typically, "Well I need to ask my boss whether we're allowed to do that" then tell your boss that the project really needs the boss to be the Stakeholder, not you.
• Be prepared to commit a minimum of 2-3 hours a week to the project. If you cannot commit to the time, then having you in the loop just creates additional communications overhead for the project team.
• If you are primary stakeholder or if you are providing extensive documentation, business expertise, or testing support then expect this time commitment to be considerably higher. For example, we had a project to deliver a new B2B order entry system. One of our stakeholders was the person who ran the B2B business. During requirements gathering, she was involved in the project about 20-30 hours a week. During development, she was involved about 10 hours a week to clarify requirements, approve changes, etc. During testing, she was involved 40-50 hours a week to help test key functionality, provide clarification on missing requirements, facilitate testing with other people in her department, etc.
• Stakeholders should be established up front and given ample warning of expectations. You should know you're on a project from the beginning even if you won't be needed until further down the line. In addition, you should have a context for the entire project and not just be isolated to your area.
• Beware of people randomly assigning you as a Stakeholder through conversations in the hall, informal emails, etc. It may come back at you if the project turns south.
• The inverse of the above is don't assign yourself as a Stakeholder simply because you're in a position of power. Simply inserting yourself into a project is not an effective way to be a Stakeholder. In addition, don't take credit for projects where you just went to a single meeting - that's not being a Stakeholder!
• If you work in a traditional departmental structure, switching to a project based model will require radical changes in how department heads interact with project teams. Many Directors assume that if a single resource of their department is on any project, they automatically get to have a say in every project decision. Even worse, some Directors simply reserve the right to sit on the sidelines and snipe at the project teams at any time at random. You'll see this in emails coming from Directors that start with, "I noticed this project is trying to use MY resource (equipment, people, brains, etc.) and before I ALLOW YOU to do so, I must REVIEW AND APPROVE this project". Don't assume that just because you're a Director you're automatically a Stakeholder on every project!
• Avoid projects where there are many Stakeholders, especially if there is no Stakeholder hierarchy or specific areas of ownership. Here is a good sign of too many stakeholders - if there are more stakeholders than project team members!
• Try to be on projects where you have a personal interest in their success. This creates investment, accountability and passion. Part of your role as a Stakeholder is to be a champion, so having a personal stake in the success of the project makes a huge difference for you and the project team. If your career is on the line because of a project, do you think you're going to be a great Stakeholder and do what it takes to be responsive? Lesson to executives - make your Directors bonuses tied to project targets, goals and successes and not just the running of the department.

Depending on where you work, you will more or less control over the projects in which you are responsible. However, all this means is that the techniques you use are more or less political There are lots of ways to get on and off a project - some of them explicit and some of them implicit (More on this in future posts). In addition, if you have no choice but to be the Stakeholder for a project then there are things you can do to improve your contribution to the project and ensure a greater chance of success.

Stay tuned for future posts for more recommendations on how to be a better Stakeholder...

Why Agile Software Projects are Good for Customers

We have two software projects that are going on at the Foundation. Project #1 is just finishing. It was not managed by me and it was done using a traditional waterfall death march type methodology. Project #2 is being managed by me and we're using a traditional Agile project management approach.

Comparing the two projects really shows the different in the benefits and obligations of the customer in an agile project:

• Project #1 is 100% over original estimate for no apparent reason. The customer gave up trying to even get a date from because they haven't seen any deliverables, don't even really understand the scope of work and just want it done.
• In Project #1, there was about 1 month just spent trying to define requirements. There were dozens of meetings trying to nail down field mappings with no code being written in the meantime (which starts to explain why the project is late). The right people were never in the room and the developers got different answers from different people.
• In Project #1, despite the investment in time, the output in terms of requirements documentation and certainty of scope was quite poor. Despite the investment, the requirements still changed up until the last week before testing including major business rule corrections.
• In Project #2, we've taken a traditional Agile PM approach. We include the customer in every meeting (usually once a week) and we are using a combination of use cases and wire frames to document requirements. This is the first time in the organization that the customers have seen either format so its a bit of a learning curve in terms of how to read them. But it took about an hour of reading through use cases before the customer fundamentally got the value of such a document.
• In Project #2, I got my lead technical architect to start prototyping on day one. By week 2 of the project, we already have a prototype writing in .NET using SQL Server 2005. The data model is about 50% done. But before even the documentation is done we have a working model.
• In Project #2 for project management we've taken an Iteration Cycle of 2 weeks as the basis for development. We have an architecture/planning/requirements spike for the first 2-3 weeks but have already started coding. Every Iteration has a plan to deliver a list of use case implementations and related wire frames as fully functional code. We have formal show and tell sessions at the end of each cycle.
• In Project #2, we have a proper project plan with real estimation. Estimation is done at the wire frame and use case level and tasks are broken down to about 1-3 days in duration. In my experience anything more granular is a waste of time and anything more becomes unpredictable and subject to error.
• In Project #2, we will be using Test Driven Development and Customer Testing all the way through the project as well as Continuous Integration.

The experience so far from a customer perspective has been really interesting so far:

• Customer participation on Project #2 has been extremely high and involved. The customer role has been really well defined and our stakeholders have been good at providing the right level of input.
• There is a good trust relationship and a sense of team - it isn't a US vs. Them approach. We're not delivering software for a customer - we're all as a team delivering on a project.
• Our ability to shift priorities and change the schedule is highly responsive. For example, our marketing department is working with the team to figure out the content for the application and its taking a lot more time than expected. So we've started on the back end logistics sections and left the front-end until the end in order to give the marketing folks the most leeway. By having check ins every two weeks we can easily adjust.
• In addition, because the application is built in vertical slices instead of horizontal ones, we don't have to have 100% of one tier done before moving to the next one. We can simply move from front end to back and hook together some disconnected pieces as they come available.
• The project is simply more fun and more of a team based approach.

Some recommendations to software project teams in treatment of their customers (whether internal or external) in an agile context:

• Don't patronize your customer because they've never done software projects before. Don't treat them like idiots because they've never read use cases or UML diagrams or database models before. If you take an hour to introduce the concepts and travel light, you'll find that customers "get it" rather quickly and then see the value of these requirements tools.
• Always remember that the customer is the end user and not a stakeholder representing an end user. For example, many Directors of Marketing act as the "customer" in web project teams. They're not. They're representing a customer. Everyone on the team needs to always focus on the end customer and stakeholders always have to be able to filter out their own biases and represent the end user successfully.
• Customers will buy into an agile project management approach if it produces results - period. If you cannot deliver software on time or its poor quality, an Agile approach won't save you and will quickly degenerate. Shorter iteration cycles means there is no where to hide, so talent/experience and ability to deliver are critical early success factors.
• Show and Tells are critical to the Agile Project. We use to have them once a week on Fridays. Make Show and Tells Fun! We use to dim the lights and use the projector and have popcorn and snacks. Even if its some boring application, hype it up and celebrate it.
• Customers should be the leading evangelists as well - some customers have been taught to be the evil task masters and try to crush development teams because they think it gets the team to work harder. I can tell you from the other side of the team that it doesn't work - developers work less, produce poorer quality and flip the bozo bit on you in short order.
• One of they values of an Agile project team is transparency and team work. Transparency is a double edged sword - customers have to be prepared to hear the bad news with the good and to help the team prioritize effectively. Good customers develop a relationship with the team that allows them to be trusted - its critical in order to encourage honest dialogue.

Overall, so far Project #2 is doing much better than Project #1. It has lots of risks and we may not be able to deliver all the functions asked for in the time line. But the requirements are well understood, communication is open and use cases are prioritized. We've already had conversations about what parts of the scope could drop if needed and contingency plans if we go late. Customers are in the loop at all times and a core member of the team.

Agile Just Feels Natural

Have done agile development for most of my career, I find it interesting when I first introduce the concepts to new developers. We're just starting to introduce it to people in my department, and we have got started with reading through the usual standard books by Ambler, Fowler, Beck, et al and I've start acting as the Agile PM on some key software projects.

What I find interesting is when I introduce it to developers, the universal reaction seems to be the following:

1. What a breath of fresh air - this is how we should have doing software all along.
2. I've already been using these techniques but didn't have a methodology to explain it and wasn't rewarded for it. I find that developers who have been raised in the classical SDLC have secretly rebelled against it and agile methodologies simply validate the rebellion.
3. The biggest flaw as most software developers experience with the traditional waterfall model (or worse the traditional death march just get it done by a fixed deadline approach) is that they now have some confidence in their work and ability to deliver against timelines.
4. When I find developers revert back to their old bad habits, they almost always run back into trouble and then slap themselves in the head of going back to hiding their risks, not being iterative and letting projects slip into death marches.

See my next post on why Agile is Great for Customers...