COLUMN

Want a project to succeed? Think about the big picture

By Debashish Chakrabarti 26 Nov 2007 | SearchSoftwareQuality.com Software quality news and advice Digg This!     StumbleUpon     Del.icio.us

Almost every project starts off with fanfare and the "stated" belief that it will help improve some aspect of an application, a system, a process, etc. Vision and mission statements abound, irrespective of whether it's an internal project or an external one for a client. What's also needed for both types of projects is proper conceptualization and execution.

Conceptualization
It might be worthwhile to consider how a project comes into being. At the very basic stage, it is an idea conceptualized in someone's head. A large number of projects that I've been associated with are actually the result of an opinion formed by a person (or a small group of people) based on their understanding and perspective of a given situation. This opinion quite often translates into a judgment call that triggers a chain of events which ultimately result in the genesis of a project. I call this approach, "Oh, this is what's wrong, and let's do XYZ to fix it."

The root cause of a lot of problems lies in the way a project is born.

The root cause of a lot of problems lies in the way a project is born. This initial impact analysis is often based on insufficient understanding, lack of context in totality, and a minimalist view of the problem statement. Or to put it bluntly, people fail to look at the big picture. There are also situations in which projects are driven through primarily on the force of personality. I call it the "Oh-he's-been-around-for-so-long-he-must-know-what-he's-doing" approach, or alternatively, the "Who's-gonna-question-him-he's-the-boss" approach.

A project conceived with improper or imperfect information or context is a bit like going out onto an unfamiliar race track in a Grand Prix with a car you haven't really tested.

If you delve deep enough, you may find that a project isn't needed.

Execution
Once you do have a project on your hands, the next thing that induces pain farther down the line is lack of appropriate and adequate planning. And by planning, I don't mean just the .mpp files of the world or the schedules and risk mitigation lists. I mean planning in totality -- the processes, the methodology, the artifacts, etc.

Select the right approach. Too many projects opt for hybrid approaches -- a bit of waterfall, a bit of incremental, a bit of agile, and tons of other artifacts and stuff -- all under the guise of adopting best practices. What we need to remember is that a best practice is, after all, a best practice in a certain context. Something that's a best practice in an agile world is likely to fall flat on its face in a more traditional project. Too often have I seen projects end up with an absolute mish-mash of processes, methodologies, etc.

Focus on quality – hard. One aspect that almost always gets affected is quality. By failing to place the right emphasis on quality, we potentially miss out on nipping quite a few problems in the bud. Testing is more than test cases or test plans or defects. Philosophically speaking, it is the art of questioning what you do (albeit in an educated fashion). It is the art by which you ask yourself as a team, "Am I doing the right thing, and am I doing it right?" That question needs to be asked as early as the project initiation.

I do see people questioning project feasibility, but as soon as you encounter the word feasibility, you have mentally already moved onto the second stage: Checking whether the project is feasible to execute. You have missed out on the first stage, which is, is this project really needed at all?

Care for your people. Planning should also include plans to understand your people. Plans are made for execution, and execution depends upon people. Too often have I seen managers, architects and leads ride roughshod over people issues or not give them due consideration.

People management is more of an art than a science -- but it's an art you need to master to a high degree to survive and excel in today's world. Inducing fun at work, understanding people and their aspirations, and leveraging human potential are not point-in-time activities. You need to be in touch with your people as regularly as you brush your teeth -- and with a comparable level of habit and familiarity. A one-off discussion in a meeting room carries more danger of alienating the person than reaching any productive conclusion.

Question yourself from the get-go, and let yourself be questioned. Think about all that you need to do, think about the big picture, and don't forget your people.

I am not naive enough to suggest this as a panacea, and I am fully aware that there exist reams of articles and research that say the same thing -- in a thousand different ways. What I suggest, however, is that this needs to be adopted as an attitude -- in the spirit intentioned -- and not as yet another best practice that ends up as a tick-mark on a checklist that has been rendered redundant by initial folly.

-----------------------------------------
About the author: Debashish Chakrabarti works as a senior associate at Sapient Corp. He has worked in IT and testing for approximately eight years and has dealt with functional testing, non-functional testing and test management.

Sound Off! -   Be the first to post a message to Sound Off!

Tags: Software project management methods and approaches,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us