Article Menu

Tuesday, 05 January 2010 13:31

Small Projects Drive Me Crazy!

Written by 
Rate this item
(0 votes)
OK, it is not small projects that drive me crazy. It is what I see project teams doing because a project is classified as a "small" project. Teams get the feeling that there is no need for a BA, no need to follow a process, and/or no need to plan. All of these thoughts just because the project has been labeled as a small project! That's what drives me bonkers. And what happens on most of these projects? Teams struggle, things are missed, and at the end of this small project, teams scramble to finish up. Of course, no project retrospective is done because; well...it was a small project.

My philosophy is that every project is different, and the team needs to take the steps that add value to the project. This does not mean planning is not important or following a process is not important. It means plan as much as necessary and take the steps in the processes that are needed. You need to analyze each project and determine what makes sense. I know many companies that try to classify projects by size, and then decide if a BA is needed, what techniques to use, how much to document, etc. I have heard people say a small project should have less than 50 pages in a requirements package. So if there are 60 do we no longer classify the project as small? Why try to keep a BA to documenting "x" number of pages? The number of pages should reflect what is needed for that project. The problem with this approach is that projects do not easily fall into buckets. There are too many factors that you need to consider in order to determine what techniques to use, and so on. The type of project, the people on the project, and internal company processes are all high-level factors that need to be considered. Putting projects in buckets opens the team up for failure and focuses the team's attention on rules in a process. Their attention should be on the customer and the goals of the project.

Teams come up with a process for small projects that are different than large projects because teams try sticking to a prescribed process for every project. Trying to implement every step in a process is overkill for some projects. Coming up with another prescribed process does not solve the problem. In my Going Rogue blog post I think some of you had the impression I do not believe in having a process, or not needing a process as you get more experience. That is not the case. What is true; I don't believe in a strict prescribed process for everyone and every project. I do believe in a process. It just needs to be fluid and ever-evolving. It has been proven by smarter people than me that having a repeatable process is the key to improvement. A process gives you an anchor to track areas of success and areas for improvement. So, I do believe a process is absolutely necessary.

The only step in a process I can say for sure is needed for every project is planning. For every project the step that must always happen and be taken upfront for a BA is plan the approach for each project. From that plan a determination will be made as to what techniques to use, how much to document, etc. For the techniques chosen, the BA should use the rules or guidelines outlined in the overall process. For example, if use cases are planned to be written for the project, the BA should use the template provided. A BA does not need to complete every step in a process, but if they do perform a step they need to be consistent with the other BAs in the organization.

Projects are not an exact science, so don't try to place a prescribed process for each and every project. Try to understand the variables of the project, the people, the internal processes, and then plan your approach. I approach projects like I approach my kids. They are each very different, so I treat them in the manner that is best for them. I do not cheer for my oldest daughter at sporting events because she shuts down and stops playing. My son loves when I scream like a raging lunatic at games because he thinks it's funny. I say it motivates him and he does not want to admit it yet! My youngest daughter, well, I have not figured her out yet!

Happy New Year everyone. I am looking forward to another year of great discussions on the profession we all love!

Kupe

Don't forget to leave your comments below

Jonathan "Kupe" Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at This email address is being protected from spambots. You need JavaScript enabled to view it.

Read 2570 times Last modified on Tuesday, 27 March 2012 13:46
Published in Kupe Kupersmith
Kupe Kupersmith

Kupe Kupersmith, President, B2T Training, possesses over 14 years of experience in the business analysis profession. He has served as the lead Business Analyst and Project Manager on projects in the utility, television and sports management and marketing industries. Kupe is a Certified Business Analysis Professional (CBAP) through the IIBA. Kupe is a trained improvisational actor and performed for years in clubs around Atlanta.  He is a big believer that we can work and learn while having fun. Kupe is a connector and has a goal in life to meet everyone!

Latest from Kupe Kupersmith

More in this category: « Treat Your Career Like Weight Watchers The Sadness of the Silo'd BA »

Comments  

 
0 # Paul Mulvey 2010-01-05 05:28
Kupe - you're opening up a whole can of worms with this post. True, small projects sometimes get classified as maintenance, and assigned directly to development. When the BA does not get assigned to the project, developers tend to go int "how do I implement a solution to this request?" mode. I'm not knocking them but their job is to find a solution and implement it. If a BA is not assigned, often the question (or dare I say, the challenge) as to why the business is undertaking this request, or digging into what the true business problem is, never gets asked. I like the thought that while you don't have a single process that works for every project, you are process-ish. There are certainly steps that you can take for every project, and some projects require you to go into more depth than others. I tend to be a process-centric person, others tend to be more PMs (but you already wrote about that in another post). For every project, you need to evaluate how much effort that you need to put in so that you can understand the business. For instance, the request may be to add an export of information from one screen to a CSV file. Simple enough request, a small project, Developers can handle it - no BA necessary. However, if a BA had been assigned, digging into the business process would have uncovered the reason for the request was to get information extracted from one system and import into another to complete a business process. A better solution may have been to have the first system automatically populate the second system without the manual steps of extracting the CSV file, saving it, importing it, and then continuing with work.
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2010-01-05 06:13
You know I love opening a cans of worms! Thanks for commenting. Your last paragraph is why those "small" projects make me a little crazy!!
Reply | Reply with quote | Quote
 
 
0 # A Kaseno 2010-01-05 06:24
A project should be a project / maintenance is maintenance. I agree when a project is classified as small, too many development processes either try to use the "one-size-fits- all" methodology or go to the "laize faire" methodology. W hen the org tries to use a too-big methodology for a small project, so much of the processes are overkill. This frustrates the team and the next thing you know either everything is slipping or everyone is complaining about all steps (not just the overkill steps) When the org does not have a legitimate small project methodology the project is approached as a laize faire project, chaos reigns. Nothing is thought out, nothing is documented and too little is accomplished for too much $$. Unfortunat ely much of the overhead of a good project is pretty consistent among all sizes of projects. Too often a project is a "small project" because the business can only afford a small project. They cut corners in an attempt to get the most from the money allocated -- generally a bad choice.
Reply | Reply with quote | Quote
 
 
0 # Nima Evans 2010-01-05 06:38
I don't understand the concept behind selective BA assignment; it is counter productive and leads to a gap between the BAs and the developers. When I was a developer, I loved to work on small tasks when the BA came to me and said "look, there's a small thing we need to do here, what do you think?" It gave me the sense of being needed and appreciated. On the contrary, I despised a working environment where the mindset was that a BA is too valuable to work on a small project: I particularly hated when a BA who was yonger and less educated than me spent their day in meetings with the big guys, and when I asked what do they want me to do with a given small issue, looked at me with a smirk saying "look, I don't know, don't waste my time, do something yourself" I believe it is a very counterproducti ve team bulding practice to do this...
Reply | Reply with quote | Quote
 
 
0 # Michael Drezga 2010-01-05 08:23
Interesting topic, we're all different and I tend to like small projects because they're more likely (in my experience) to deliver something! I've recently worked on a couple of stalled/failed projects and have gone back to working in the small project space and can definitely say its good to be back :o) We have a methodology for small, medium and large etc but its so loosely governed that its not adhered to at all, great in theory, but like everything you need commitment/doll ars from management to apply the correct approach to each project size/complexity . Similar to building a house, if I want to build a one bedroom house then I'll still have to follow a plan (on A4), a schedule etc, however I may not have the complexity of building in a swimming pool. On the other hand, if I want to build an apartment buildling I will have to follow a plan (on many A4s), a bigger schedule and will have to manage a greater number of factors, risks, people in comparison to just buildling a one bedroom house. I like the whole 60 page standard mentioned, its like the whole "never let the truth get in the way of a good story" line....for BAs its "never let in-scope items get in the way of a good product!" Back to work!
Reply | Reply with quote | Quote
 
 
0 # Søren Hjelholt 2010-01-05 17:04
I share your thoughts on the whole tayloring of project processes idea. I have, like you, for a long time been an advocate of doing what makes sense in the current project, and not doing everything the process says. It is however sometimes difficult to get this point across to project management, as they sometimes tend to be more focused on the means rather than the end product. As a BA I actually like to work on smaller projects. I usually have a lot more influence on the activities needed to be carried out and can participate in the structuring of the process. Omn larger projects with several BA's, PMs, Solution Architects etc. it's often tougher to have the overview of the whole project and who does what.
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2010-01-05 23:57
@hjelholt and @bamad, I'm with you. I like to work on small projects where you quickly see results. I just think many organizations do not focus on the right things when it comes to small initiatives and cause more headache than results. Thanks for reading and commenting!
Reply | Reply with quote | Quote
 
 
0 # Jarett Hailes 2010-01-06 00:25
Good discussion - I find it interesting that so many of us have found that smaller projects 'get more done'. Perhaps large projects have an even greater potential to be misaligned with an appropriate process as well. With smaller projects that misalignment is less critical since it is easier to overcome being prescribed the wrong process (or lack thereof). I agree that when a project is struck there should be an evaluation of the process needed in order to keep the project on track and strike the balance between procedure and innovation. I usually try to apply a 'just enough' theory - start light and look for signs that there isn't enough process to keep everyone moving in the right direction. Regardless of the process, you need the right skill set in order to accomplish the tasks at hand, and that usually means you need all types of skills (PM, BA, developer, tester, etc.) on a project, regardless of size. Just because the total effort is less doesn't mean that any of these areas can be neglected. I think PMOs and service organizations need to consider how to handle projects that don't require full time personnel without neglecting the needed skill sets in order to achieve success.
Reply | Reply with quote | Quote
 
 
0 # Alison Ibarguen 2010-01-06 22:01
I agree with so much of the above and would like to add that perhaps the technical team should be trained in BA skills (at least the basics) if they are expected to perform BA activities.
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2010-01-07 02:51
I'm with you. I don't care about your title. Someone on the team needs to do the BA activities!
Reply | Reply with quote | Quote
 
 
0 # Bill 2010-01-07 09:12
Good article; love the attitude of common sense and a flexible approach - what a concept! I've worked with more than a few people from devs to BAs to management who didn't "get" this; they simply couldn't step back and really LOOK at the project/situati on. All they knew was we have process XYZ and heaven forbid we step outside of it. Hello McFly. Bottom line: projects can and do vary in many ways and there is no "cookie cutter" right answer on how to approach them - although certainly a uniform approach for similar types (in general) is something to strive for. One thing that struck me reading this was when I was part of a small project that was actually part of a bigger one (does that have "Agile" written all over it or what?). The project itself didn't need much in the way of a BA or "BA activities" per se, but got it anyway because of its place as a cog in the overall machine, so to speak.
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2010-01-07 21:57
@ billr - Thanks for the comment! I can agree with you that a person with the title of Business Analyst is not needed on a project. But, when you say no BA activities were not needed I can't back you up! Can you clarify what you mean by no BA activities? Thanks for keeping the conversation going.
Reply | Reply with quote | Quote
 
 
0 # Bill 2010-01-08 08:27
Small but significant clarification: I didn't say "no" BA activities, but rather "not much." :) I think even the smallest project is almost certainly going to have SOME kind of BA activity, even if it's very simple/small in nature and perhaps done by someone other than a BA. Fair? (PS: I also thought of another variance: where people draw the line at what's considered a "project")
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2010-01-08 21:48
Now I gotcha...very fair!!!! And yes the is it a project question can throw a wrinkle into things. Some earlier commenters touched on that. You may have just sparked an idea for a post! Thanks @billr
Reply | Reply with quote | Quote
 
 
0 # Gerwin Cuenca 2010-01-10 08:49
Again, a great post. I couldn't agree more with your thoughts especially on the 'practice' of categorizing projects by size and applying a prescribed process based on that perceived size. There are indeed so many factors that come into play in different projects and pigeon-holing (if there's such a verb) a project using this method could set it up for failure. No matter what the perceived size of the project is, a BA's involvement to assess and analyse the project thoroughly is, I believe, a pre-requisite.
Reply | Reply with quote | Quote
 
 
0 # Holly Martin 2010-01-12 02:06
The joke in my dept is if you don't want the project to be classified "small" (or you want to kill it) assign Holly the BA to it. Because my requirements are so thorough I guess people get overwhelmed and think they just can do it. What they originally committed to as a "small" project has suddenly become large. Irony is that if someone didn't do thorough analysis at the beginning then they would have caught all this stuff much later in the project life cycle and it ultimately would have evolved to a large project anyway (and been more costly to the company). So I'm always humored by people who judge a project size before scope or requirements is complete. The classification "small" ends up being the excuse for getting something in under the radar.
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2010-01-12 02:48
@ hkmartin, I love that! Thanks for the comment @gvcue nca, I'm thrilled you are enjoying the posts. I am with you on the pre-requisite!
Reply | Reply with quote | Quote
 
 
0 # Hans Eckman 2010-01-12 03:18
Kupe, well stated. There are no small projects, only small budgets. The question I find most is how much process, steps, and documentation is the team willing to forgo to keep the cost down. By reducing time in analysis and design, the company will just pay 4-10 times as much in development, testing, and maintenance. Then again, maintenance falls under someone else's budget.
Reply | Reply with quote | Quote
 
 
0 # Robert Dubois 2010-01-12 05:37
Kupe, You are spot on that processes should be tailored to the needs of the project and planning is the first required step. What I continue to wrestle with and have for years is why this industry struggles with processes and project success at all levels. I keep returning to three potential elements. This is posted to in two parts due to the comment length restrictions. One is that software development is still in an infancy state when you compare it to other industries where construction of a product takes place. Granted we have come a long way from punch cards, but compared to other industries we are just getting started. We still have a lot of learning and education to go. The second element I believe is a result of the fact that we do not have any perceived material costs, as you would say in the construction of a building or structure. Our costs exist in resources and as a result, there is no material loss for rework, only time. Moving a wall versus adding a field creates a paradigm shift not been fully realized. This is what I believe has driven the mentality of; if we are not coding we are not productive. Shortcuts are taken and other activities are less valued and diminished. This results in repeated attempts to classify or compartmentaliz e projects. Organizations continue to seek out that singular silver bullet that will encompass the full spectrum of projects. End Part 1
Reply | Reply with quote | Quote
 
 
0 # Robert Dubois 2010-01-12 05:38
Part 2 from rdubtx post The third element has to do with what this industry is primarily about. That is - our ability to capture in 1 and 0s the intellectual activities of the human mind in some sort of definitive, predictable, consistent, adaptable… way in order to . No two groups of stakeholders are identical, no two people think, act or respond in the same way, and no two projects are the same. Through the efforts of folks found here responding to this blog and the industry as a whole, we will slowly and surely mature and overcome these challenges. We are unique in what we do and we are on the defining edge of new industry when compared to others that have been around for hundreds of years. Thanks for being out there to help grow and mature this discipline and industry as it continues to evolve and works through its many growing pains, frustrations and successes. Happy New Year.
Reply | Reply with quote | Quote
 
 
0 # Angela Wick 2010-01-12 22:40
Agree, that cost of a "small project" if the BA role is not carried out becomes as large as a normal or big project once you account for the delays, defects, and missed requirements . . . not to mention the missed opportunities and cost to maintain. Ange la @WickAng
Reply | Reply with quote | Quote
 

Add comment

back to top