Category Archives: Project Management

Why you need to buy @berkun’s new “Mindfire” book…

I’ve been reading Scott Berkun’s new book, Mindfire.

I’m not going to review it in this post, I’ll save that for later.

However, I’m will tell you why you should buy it!

Scott self-published Mindfire, a feat worthy of huge congratulations. He did so for a number of reasons. I was particularly taken by this one:

So, you should buy Mindfire if only to learn what it is Scott would like to write about that makes publishers run a mile.

I have deliberately added this post to the Project Management category, Scott is the project management guy 😉

Software projects that are over-budget and late: please, don’t blame us…

[Originally drafted in March 2010, published February 2011]

For many decades now, developers and IT departments have been at the receiving end of a lot flack. Flack stemming from the fact that many software projects cost more than originally estimated and take longer to reach production than previously thought. Typically, it’s the fault of the folks near the bottom of the tree: the developers or the IT department. This blog post is a tale of woe that highlights the blame culture that we live in and how this author believes that blame to be misdirected, at least in some cases.

Most software projects have some sort of plan, a list of activities, a product backlog, user stories, perhaps even a schedule. Regardless of your religious view in the waterfall or agile space, you will have requirements noted down somewhere using whatever technique floats your boat. You may also have an “end date” (aka a go live date) that is either dictated by some form of time estimate based on the list of activities or, worse, by a third party. Invariably, you may not have a lot of say in the estimation process…you have to hope that the person is reasonably good at estimating how long it will take a somebody else to complete a task. Remember, that person is estimating how much time somebody else needs to complete a task: a task in a domain they most probably know very little about (“stick a button on that form there, how hard can it be?”)

Thinking about scope: can you produce a flowchart outlining your current process, the process that you want a magical application to replace? If you can’t produce a flowchart, how do you expect other people to understand the start point, the processing and the end point? You can expect some help from your developer, programmer or system implementor when it comes to documenting your current workflow; equally you can expect some help from them when it comes to documenting your requirements. However, don’t turn to your developer, programmer or system implementor and tell them that you don’t have the time to document the requirements or document the workflow. If you don’t have time to tell us what you want in the first place, we know (from experience) that you’ll not have time to help us with user acceptance testing later on in the project – assuming we can build a system worthy of user acceptance testing in the absence of any real requirements.

All too often developers and IT departments have been getting it in the neck for project failures. However, little has been said about the fact that the blame really lies with those further up the project hierarchy. Failure to provide adequate work scope / definition results in confusion and the potential for large amounts of scrap and rework. Developers don’t mind throwing code away as a result of refactoring, however they do mind shelving code because it has suddenly become redundant or is now not part of the solution.

In a recent current project I was told “we don’t have time to write a specification”. However, we do have the time to overrun by many months and we do have the budget to fund the additional development and to cover the opportunities that are lost. With no end in sight, developer morale takes a hit, they lose direction. Similarly, there can be nothing worse for a developer to be on a project where s/he doesn’t know what they are meant to be doing? And worse, if they do find out what they are meant to be doing, to have it change from one week to the next. Or even to have it [the glimmer of hope, the taste of the requirement] change from day to day.

In the absence of a specification, feature creep is inevitable. Development cycles feel, and often are, endless. Even with an understanding and helpful client, the absence of a specification is a golden ticket for those who want everything from the system. Specification-less projects suffer from feature creep and work scope additions. All of the “nice to haves” suddenly come out of the woodwork. And because there’s little in the way of contractual documentation in place to lay down the law or draw the line in the sand, there’s nothing you can do apart from argue your case against adding features. The time you spend arguing your case, is time you’re not working on the project, you’re not progessing the project towards completion, the delay gets worse. Mind you, perhaps it’s a good thing that you’re not working on the project, after all, do you know what you’re meant to be doing?

Software development is a complicated process.  Unstructured and unproven time/budget “guesstimation” just doesn’t work in this industry.  You can’t say to software developer “two weeks” to write an enterprise class system that replicates the functionality of commercial of the shelf software costing many ÂŁ000’s per license.  Two weeks is how long it might take you to cut’n’paste a spreadsheet together…it’s hardly long enough to develop all but the most simple functionality.  In the absence of a specification, database schemas are an ever-changing beast.  In most data-driven applications, the database schema is comparable to the foundations of a building.  The foundations are not something you want to change half way through the development.  Granted, clever people have written applications with dynamic database schemas…but they weren’t written in two weeks, or part thereof. 

After the database design, there’s the user interface.  Yes, it is easy to drop a button on a form!  What’s not so easy is what that button does when you click on it.  Anything beyond MessageBox.Show(“Hello, world!”); is where the time is spent.  I’m grateful to have seen multi-page specifications for the action behind a single button – if you can find somebody willing to invest the time and effort in writing such detail, the payoff is amazing. However, such people are few and far between. In today’s day and age, agile is where it’s at and user stories are King. Ultimately, it’s an emotive topic and one that I will not debate here (although you are free to discuss in the comments) – I don’t mind how you capture requirements, as long as you do.

Software developers struggle to work with “what’s in your head today”, knowing from experience that it will change tomorrow. Even in the agile world, there has to be an element of commitment: if you change your mind day after day, you’ll get a reputation and folks will end up using baseball bats to extract requirements. That’s not a good look, trust me on that. Oh, and don’t take the picture too literally: don’t do things on a handshake, that doesn’t work either: put something in writing, a contract, something that sets the scene and defines the lay of the land.

Requirements: however you document them – they are the light at the end of the tunnel for you and for the developer / development team. If your developer / development team ask you for “better requirements” very early in the project (or, shoot, even at the very start of the project), don’t dismiss it. Listen to them, they probably have a point. They are the folks who’ll be writing the software and they are the folks who’ll struggle to prepare a deliverable based on incomplete or inaccurate scribbles on whiteboard or sheets of paper.

Requirements: abuse them at your peril. In the absence of requirements, prepare yourself for a bottom-less pit that will consume time, money, other potential projects/opportunities and the morale of your development team.

Considered Reading

PM#11 – Management By Shouting Loudest (MBSL)

[Originally drafted in 2008, published 2011 with minor modifications]

Via http://mysite.verizon.net/charliez/murphy.htm

Swipple’s Rule of Order
He who shouts loudest has the floor.

He who does shout loudest and takes the floor, often fails to realise that there may well be other people who can’t or won’t shout louder. Thus we find ourselves in a position whereby other folks’ opinions are either not heard or become of secondary value: there is a huge lost opportunity. It’s a lost opportunity because those folks whose ideas and opinions that are not heard, may well be better than those offered by the people who shout the loudest. Shouting the loudest may also be referred to as Management By Shouting Loudest (MBSL).

Similarly, he who shouts loudest may believe that their contribution or their requirements should take priority over those contributions suggested by others. Where prioritisation is assumed, one needs to consider the knock-on effect – whenever something becomes your top priority, something has to give. A lack of warning or preparation on the part of others means we suddenly have an emergency to deal with. It’s also about respecting folks’ schedules – folks in IT don’t sit at our desks twiddling our thumbs waiting for your emergency to happen (a common misconception that affects the IT industry on a large scale).

If you do succumb to accepting a task from somebody who shouts the loudest, think about the impact it has on your current schedule. What is being sacrificed? What is going to take longer to complete? Apart from yourself, who are you letting down as a result of accepting the MBSL task?

It’s no wonder that “he who shouts loudest” is a very old trick and one that is still in use today. Watch out for it, try to curb its use by catching it early: try and coach the person doing the shouting into adopting a more democratic approach. Look out for lost opportunity moments, capture those, give them air time – you may be surprised how much innovation is lost by accepting the MBSL way.

In this series:
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

26th – 30th July 2010 – London – Professional Scrum Developer (.NET) – 50% discount

On the 26th – 30th July in Microsoft’s offices in London Adam Cogan from SSW will be presenting the first Professional Scrum Developer course in the UK. Martin Hinshelwood will be teaching this course along side Adam and it is a fantastic experience. You are split into teams and go head-to-head to deliver units of potentially shippable work in four two hour sprints.

Update 18th June 2010 – SSW is offering a massive 50% discount to make this 5 day course only ÂŁ1,168…I have been told that this depends on availability so it may go back up.


ProfessionalScrumDeveloper_200px[3]

The Professional Scrum Developer course is the only course endorsed by both Microsoft and Ken Schwaber and they have worked together very effectively in brining this course to fruition. This course is the brain child of Richard Hundhausen, a Microsoft Regional Director, and both Adam and I attending the Trainer Prep in Sydney when he was there earlier this year. He is a fantastic trainer and no matter where you do this course you can be safe in the knowledge that he has trained and vetted all of the teachers. A tools version of Ken if you will Wink
LondonCallToAction[1]

If you are outside the UK you can find out where this course is being run near you. Make sure you have a look at the scrum guide from Scrum.org and the syllabus from Accentient.


What is the Professional Scrum Developer course all about?

imageProfessional Scrum Developer course is a unique and intensive five-day experience for software developers. The course guides teams on how to turn product requirements into potentially shippable increments of software using the Scrum framework, Visual Studio 2010, and modern software engineering practices. Attendees will work in self-organizing, self-managing teams using a common instance of Team Foundation Server 2010.

Figure: Sam and Ken discuss the PSD Course

Who should attend this course?

This course is suitable for any member of a software development team – architect, programmer, database developer, tester, etc. Entire teams are encouraged to attend and experience the course together, but individuals are welcome too.

Attendees will self-organize to form cross-functional Scrum teams. These teams require an aggregate of skills specific to the selected case study. Please see the last page of this document for specific details.

Product Owners, ScrumMasters, and other stakeholders are welcome too, but keep in mind that everyone who attends will be expected to commit to work and pull their weight on a Scrum team.

What should you know by the end of the course?

Scrum will be experienced through a combination of lecture, demonstration, discussion, and hands-on exercises. Attendees will learn how to do Scrum correctly while being coached and critiqued by the instructor, in the following topic areas:

  • Form effective teams
  • Explore and understand legacy “Brownfield” architecture
  • Define quality attributes, acceptance criteria, and “done”
  • Create automated builds
  • How to handle software hotfixes
  • Verify that bugs are identified and eliminated
  • Plan releases and sprints
  • Estimate product backlog items
  • Create and manage a sprint backlog
  • Hold an effective sprint review
  • Improve your process by using retrospectives
  • Use emergent architecture to avoid technical debt
  • Use Test Driven Development as a design tool
  • Setup and leverage continuous integration
  • Use Test Impact Analysis to decrease testing times
  • Manage SQL Server development in an Agile way
  • Use .NET and T-SQL refactoring effectively
  • Build, deploy, and test SQL Server databases
  • Create and manage test plans and cases
  • Create, run, record, and play back manual tests
  • Setup a branching strategy and branch code
  • Write more maintainable code
  • Identify and eliminate people and process dysfunctions
  • Inspect and improve your team’s software development process

What does the week look like?

This course is a mix of lecture, demonstration, group discussion, simulation, and hands-on software development. The bulk of the course will be spent working as a team on a case study application delivering increments of new functionality in mini-sprints. Here is the week at a glance:

image

Monday morning and most of the day Friday will be spent with the computers powered off, so you can focus on sharpening your game of Scrum and avoiding the common pitfalls when implementing it.

The Sprints

Timeboxing is a critical concept in Scrum as well as in this course. We expect each team and student to understand and obey all of the timeboxes. The timebox duration will always be clearly displayed during each activity. Expect the instructor to enforce it.

Each of the ½ day sprints will roughly follow this schedule:

Component Description Minutes
Instruction Presentation and demonstration of new and relevant tools & practices 60
Sprint planning meeting Product owner presents backlog; each team commits to delivering functionality 10
Sprint planning meeting Each team determines how to build the functionality 10
The Sprint The team self-organizes and self-manages to complete their tasks 120
Sprint Review meeting Each team will present their increment of functionality to the other teams ≤ 30
Sprint Retrospective A group retrospective meeting will be held to inspect and adapt 10

Each team is expected to self-organize and manage their own work during the sprint. Pairing is highly encouraged. The instructor/product owner will be available if there are questions or impediments, but will be hands-off by default. You should be prepared to communicate and work with your team members in order to achieve your sprint goal. If you have development-related questions or get stuck, your partner or team should be your first level of support.

Module 1: INTRODUCTION

This module provides a chance for the attendees to get to know the instructors as well as each other. The Professional Scrum Developer program, as well as the day by day agenda, will be explained. Finally, the Scrum team will be selected and assembled so that the forming, storming, norming, and performing can begin.

  • Trainer and student introductions
  • Professional Scrum Developer program
  • Agenda
  • Logistics
  • Team formation
  • Retrospective

Module 2: SCRUMDAMENTALS

This module provides a level-setting understanding of the Scrum framework including the roles, timeboxes, and artifacts. The team will then experience Scrum firsthand by simulating a multi-day sprint of product development, including planning, review, and retrospective meetings.

  • Scrum overview
  • Scrum roles
  • Scrum timeboxes (ceremonies)
  • Scrum artifacts
  • Simulation
  • Retrospective

It’s required that you read Ken Schwaber’s Scrum Guide in preparation for this module and course.

MODULE 3: IMPLEMENTING SCRUM IN VISUAL STUDIO 2010

This module demonstrates how to implement Scrum in Visual Studio 2010 using a Scrum process template*. The team will learn the mapping between the Scrum concepts and how they are implemented in the tool. After connecting to the shared Team Foundation Server, the team members will then return to the simulation – this time using Visual Studio to manage their product development.

  • Mapping Scrum to Visual Studio 2010
  • User Story work items
  • Task work items
  • Bug work items
  • Demonstration
  • Simulation
  • Retrospective

Module 4: THE CASE STUDY

In this module the team is introduced to their problem domain for the week. A kickoff meeting by the Product Owner (the instructor) will set the stage for the why and what that will take during the upcoming sprints. The team will then define the quality attributes of the project and their definition of “done.” The legacy application code will be downloaded, built, and explored, so that any bugs can be discovered and reported.

  • Introduction to the case study
  • Download the source code, build, and explore the application
  • Define the quality attributes for the project
  • Define “done”
  • How to file effective bugs in Visual Studio 2010
  • Retrospective

Module 5: HOTFIX

This module drops the team directly into a Brownfield (legacy) experience by forcing them to analyze the existing application’s architecture and code in order to locate and fix the Product Owner’s high-priority bug(s). The team will learn best practices around finding, testing, fixing, validating, and closing a bug.

  • How to use Architecture Explorer to visualize and explore
  • Create a unit test to validate the existence of a bug
  • Find and fix the bug
  • Validate and close the bug
  • Retrospective

Module 6: PLANNING

This short module introduces the team to release and sprint planning within Visual Studio 2010. The team will define and capture their goals as well as other important planning information.

  • Release vs. Sprint planning
  • Release planning and the Product Backlog
  • Product Backlog prioritization
  • Acceptance criteria and tests
  • Sprint planning and the Sprint Backlog
  • Creating and linking Sprint tasks
  • Retrospective

At this point the team will have the knowledge of Scrum, Visual Studio 2010, and the case study application to begin developing increments of potentially shippable functionality that meet their definition of done.

Module 7: EMERGENT ARCHITECTURE

This module introduces the architectural practices and tools a team can use to develop a valid design on which to develop new functionality. The teams will learn how Scrum supports good architecture and design practices. After the discussion, the teams will be presented with the product owner’s prioritized backlog so that they may select and commit to the functionality they can deliver in this sprint.

  • Architecture and Scrum
  • Emergent architecture
  • Principles, patterns, and practices
  • Visual Studio 2010 modeling tools
  • UML and layer diagrams
  • SPRINT 1
  • Retrospective

Module 8: TEST DRIVEN DEVELOPMENT

This module introduces Test Driven Development as a design tool and how to implement it using Visual Studio 2010. To maximize productivity and quality, a Scrum team should setup Continuous Integration to regularly build every team member’s code changes and run regression tests. Refactoring will also be defined and demonstrated in combination with Visual Studio’s Test Impact Analysis to efficiently re-run just those tests which were impacted by refactoring.

  • Continuous integration
  • Team Foundation Build
  • Test Driven Development (TDD)
  • Refactoring
  • Test Impact Analysis
  • SPRINT 2
  • Retrospective

Module 9: AGILE DATABASE DEVELOPMENT

This module lets the SQL Server database developers in on a little secret – they can be agile too. By using the database projects in Visual Studio 2010, the database developers can join the rest of the team. The students will see how to apply Agile database techniques within Visual Studio to support the SQL Server 2005/2008/2008R2 development lifecycle.

  • Agile database development
  • Visual Studio database projects
  • Importing schema and scripts
  • Building and deploying
  • Generating data
  • Unit testing
  • SPRINT 3
  • Retrospective

Module 10: SHIP IT

Teams need to know that just because they like the functionality doesn’t mean the Product Owner will. This module revisits acceptance criteria as it pertains to acceptance testing. By refining acceptance criteria into manual test steps, team members can execute the tests, recording the results and reporting bugs in a number of ways. Manual tests will be defined and executed using the Microsoft Test Manager tool. As the Sprint completes and an increment of functionality is delivered, the team will also learn why and when they should create a branch of the codeline.

  • Acceptance criteria
  • Testing in Visual Studio 2010
  • Microsoft Test Manager
  • Writing and running manual tests
  • Branching
  • SPRINT 4
  • Retrospective

Module 11: OVERCOMING DYSFUNCTION

This module introduces the many types of people, process, and tool dysfunctions that teams face in the real world. Many dysfunctions and scenarios will be identified, along with ideas and discussion for how a team might mitigate them. This module will enable you and your team to move toward independence and improve your game of Scrum when you depart class.

  • Scrum-butts and flaccid Scrum
  • Best practices working as a team
  • Team challenges
  • ScrumMaster challenges
  • Product Owner challenges
  • Stakeholder challenges
  • Course Retrospective

What will be expected of you and you team?

 
This is a unique course in that it’s technically-focused, team-based, and employs timeboxes. It demands that the members of the teams self-organize and self-manage their own work to collaboratively develop increments of software.

All attendees must commit to:

  • Pay attention to all lectures and demonstrations
  • Participate in team and group discussions
  • Work collaboratively with other team members
  • Obey the timebox for each activity
  • Commit to work and do your best to deliver

All teams should have these skills:

  • Understanding of Scrum
  • Familiarity with Visual Studio 201
  • C#, .NET 4.0 & ASP.NET 4.0 experience* 
  • SQL Server 2008 development experience
  • Software testing experience

* Check with the instructor ahead of time for the exact technologies

Self-organising teams

Another unique attribute of this course is that it’s a technical training class being delivered to teams of developers, not pairs, and not individuals. Ideally, your actual software development team will attend the training to ensure that all necessary skills are covered. However, if you wish to attend an open enrolment course alone or with just a couple of colleagues, realize that you may be placed on a team with other attendees. The instructor will do his or her best to ensure that each team is cross-functional to tackle the case study, but there are no guarantees. You may be required to try a new role, learn a new skill, or pair with somebody unfamiliar to you. This is just good Scrum!

Who should NOT take this course?

Because of the nature of this course, as explained above, certain types of people should probably not attend this course:

  • Students requiring command and control style instruction – there are no prescriptive/step-by-step (think traditional Microsoft Learning) labs in this course
  • Students who are unwilling to work within a timebox
  • Students who are unwilling to work collaboratively on a team
  • Students who don’t have any skill in any of the software development disciplines
  • Students who are unable to commit fully to their team – not only will this diminish the student’s learning experience, but it will also impact their team’s learning experience

 


LondonCallToAction[1]

If you are outside the UK you can find out where this course is being run near you. Make sure you have a look at the scrum guide from Scrum.org and the syllabus from Accentient.

Video: Lean, Kanban and Theory of Constraints for Managers (@roblally at @epicenter2009)

Last month Rob Lally gave an excellent presentation at epicenter 2009 in Dublin. Rob on Twitter.

We managed to record the session, which includes an excellent practical demonstration that is well worth watching. Rob’s an excellent speaker, he fills 60 minutes with great content and humour.

The application of Lean principles, Kanban and pull-systems theory along with Goldratt’s Theory of Constraints revolutionised the manufacturing world in the second half of the twentieth century. Belatedly, the software world is waking up to the transformative effects these tools can have. There are still no silver bullets in the software world, but that doesn’t mean that we can’t improve our aim.

Having applied these principles and practices to many real-world, commercially-motivated projects, Rob speaks from the perspective of a practitioner not a theorist.

Although each of the three topics is a whole field of study unto itself, Rob’s goal is to communicate some of the key lessons from each, and have attendees leave with concrete ideas that they can use to improve their organisation.

No M&Ms were hurt in the making of this video, however some were eaten. Of course, if other confectioners wish to offer their “colour-coded” products for future demonstrations, please leave a comment here: but be warned, we will only deal in large quantities 🙂

Rob Lally @ epicenter 2009, Dublin from Craig Murphy on Vimeo.

Adaptive Project Management using Scrum: my article appears in a book

I’m pleased to report that my Methods & Tools article Adaptive Project Management using Scrum has found its way into a book.

I received my complimentary copy today:

I’m not sure if the book will make the popular sites like Amazon, although it does have an ISBN of 978-81-314-1649-5 (9 788131 416495) so I guess there’s a chance you might find it somewhere. More details about the book can be found here.

As far as I understand, it’s a book by the Icfai University Press, more information can be found here.

It’s pleasing to see how an article intended for reading via a browser fits into “book sized” pages, it gives me an idea of how much I need to write in order to complete a book. So when Dell or Samsung ship me a netbook to review, you know I’ll be writing a book 🙂

Technorati Tags: , , ,

[Event] AgileMalta – 5th December 2008

I’m pleased to see AgileMalta running its second conference. I have a soft spot for Malta having essentially lived there on and off for many years. It has probably changed a lot, but I still like to think I know Malta and Gozo almost as well as I know the back of my hand. I can’t think of a better mix, the islands of Malta, Gozo and Comino, their people and an agile development conference…

What: Talks given by people who have had a hands-on experience with Agile with international clients. The Key Note speaker is Joakim Ohlrogge. Local speakers are two local persons who actively participate in Agile projects, Aldo Cauchi Savona and Dave Sammut.
Date: Friday, December 5th 2008
Location: Hilton Hotel, St. Julians
Duration: Half-day conference
Price: T.B.A.

Further details can be found here:
http://www.agilemalta.com/events/agile-conference-december-2008/

Overview:
Success in today’s software industry requires a process, an environment and people that are able to achieve business goals within tighter deadlines, without compromising quality or reducing employee moral. Your process needs to be able to be attractive to foreign investment, your employees need the skills to deliver and sustain the process.

Whether you are interested in Agile or seeing how you can improve your own development process, the AgileMalta Conference is a great opportunity for people at all levels to gather together to learn about and share experiences on Agile software development process.

In our first conference we provided talks and discussion sessions for people at all levels to come into contact and learn about Agile. In the upcoming conference we will build upon feedback from the 1st conference and from our website. We decided to provide you with talks on implementing Agile and dealing with common issues when using such a process.

Join the AgileMalta Facebook group here!

Technorati Tags: , , , , , ,

[Event] Agile Malta – 19th February 2008

1st International Conference on
Agile Development Malta 2008
The 2008 Agile Gathering is the 1st International Conference on Agile Development, to be held on February 19th, is the first event to be held in Malta section that focuses specifically on the topics of agility within the software development process. The event brings together leading industrial practitioners and users of agile within the fields of information systems and software engineering and targets the practical applications and implications of agile methods.

The conference aims to put people in touch with other agile practitioners on the Maltese islands, and give attendees an overview of practical experiences gained by companies and individuals currently practicing Scrum and other agile methods. The conference is targeted at executives, managers, software development practitioners and software engineering students.

The conference is not intended to be a place for instruction but rather an occasion for the exchange of information on agile software development in general.

Event web-site: http://www.agilemalta.com

The agenda can be found here: http://www.agilemalta.com/2008programme.php

Technorati Tags: , , , , , , , , ,

Scrum – in action at Microsoft

Via Channel 9:

Grace Francisco talks over lunch with Ellie Powers, Program Manager with the Hotmail team to find out more about Scrum and its benefits. Hear her real world feedback on using it in projects and the challenges you may encounter.

And from a while ago:

Garry Wiseman, product unit manager, and friends take us through a new Windows Live classified service named “Expo.” We get a demo of this cool new service that helps you buy and sell stuff. A place for you to find things and others to find your things. You can learn more here: http://expo.live.com

Technorati Tags: , , , , ,

“Stop Doing” Lists

I attended a two-day induction course last week. Whilst there were many useful “takeaways”, good ideas, common sense approaches, etc. the course leader presented us with a book: Good to Great by Jim Collins.

Naturally I skimmed through the table of contents, then skimmed through each chapter. One thing that I picked up from this brief read was the need for “Stop Doing” lists. These are the opposite of “To do” lists.

Since I am a great believer in lists, particularly To Do lists, I figured that Stop Doing lists deserve more of my time. We all spend a lot of time either floundering or procrastinating – we prioritise tasks based on their level of enjoyment (best tasks first), their ease of completion (low value tasks, completed before high value tasks that require longer to complete), etc.

In amongst all of the tasks that we “do”, there are activities that are of high importance (perhaps high value), those that are middle of the road and those that are of low importance (low value).

Q. How much time and effort are you putting in to service those low importance tasks? Probably more than you would like. And how much value are they bringing you?
A. Probably not enough.

Q. Are those low importance tasks impacting the service you provide to the other higher importance tasks?
A. It’s very likely that it is.

Q. If you stopped doing the low importance tasks, would the service you could deliver to the high importance tasks improve?
A. A resounding yes.

Earlier in this post, I mentioned floundering. It’s perhaps a little strong, what I mean by its use is to fumble or bumble about whilst endeavouring to complete a task. Personally, I notice that I flounder whilst trying to get out of the house in the morning (to go to work). Floundering manifests itself in many ways, in my case, I find myself making second and third trips back up the stairs – when I had previously thought that I my tasks/work upstairs was complete. It’s a petty example, but such floundering has major knock-on effects, the extra trip upstairs can mean missing a particular train, which in turn delays getting to the office by 15 minutes…

The same effect can be noticed during day-to-day project work. I’m sure that we’re all guilty of revisiting what we thought were completed tasks…or perhaps losing the focus slightly then engaging in either re-work or dilly-dallying to get things going again. I know that I find myself doing this, sometimes, I can’t be alone…and given the number of books that have been written about getting things done, I’m pretty sure that it’s not just me!

How can I identify the “stop doing” items?
I’ve seen people use the “red dot” technique, whereby they tag each work item or task with a red dot each and every time they touch it. Obviously the more often an item is touched, the more it looks like it has measles. However, whilst that method will identify some items, it won’t help you identify the low priority, low importance items, for it is these that you should be homing in on and weeding out. Everybody has a different definition of low priority, low importance, for me I’m trying to do fewer activities that impede my progress on higher value projects/items. This involves me being ruthless with any task that I believe is a time-waster, if there’s no value in it for me, it going on to the Stop Doing list.

In a nutshell, Stop Doing lists revolve around doing less of what adds little value (or little profit) to your activities whether business or personal. Instead, we should focus on doing more of those items that add more value (or more profit). By virtue of doing less (or no) low value items, we are free to spend more time concentrating on the higher value items. Those activities that we do spend time on will have more time spent on them, thus as a job, it should be done that bit better.

Food for thought…

Good To Great is also available as an audio CD.