Lesson No. 3: Choose the Simple Over the Complex

Lets take the example of an electric cooker. Something that can cook every dish possible (hypothetically of course). If I were to say, the cooker has a button to set the time you want to cook the food. Each click of the button adds 30 seconds of cooking time. So, to melt butter you press the button 2 times and to boil milk 4 times and so on. Do you really think the manufacturing team will sign-off on such a design?

The response I probably will get is “The design is too simple, there are no awesome features.” But, the fact is, the cooker has all features. It can cook anything. All the cook has to do is, know the right amount of time to cook each dish in our cooker. If this product were to come in the market, it will probably have atleast a dozen buttons with options to cook individual dishes like “one button for cooking rice”, “one button for roasting chicken” etc…

Can you guess what I am coming to here? Imagine how easy it would be to manufacture and maintain the cooker with just one button, as compared to one with 20 buttons. Isnt it?

Computer Software generally solves complex problems. The question is how much of that inherent complexity are you forcing onto the end-user? Is your software amplifying the complexity?

Good Software is something that must absorb the complexity and make the life of a user as simple as possible, instead of further complicating it.

As a software project manager, are you a complexity absorber or a complexity amplifier? The best ones absorb complexity from all sides; from the programmers, from the end-users, from management etc and never amplify it. As the end-users generate seemingly contradictory requirements, your job is to help clean them up, rather than passing them blindly on to the developers. As the developers cite possible technical reasons for not being able to fulfill a requirement, your job is to translate (absorb) that complexity and present the end-users with enough information to help them choose a different option.

How easy is it to use your application? How easy is it to add a new feature to your application? How easy is it to request a new feature? Report a bug? Deploy a new version? Roll back a bad version? For almost all these questions, your answer will be “A bit complicated I guess. It involves a lot of work and processes”. I am not against processes. Processes make our lives easier but the simpler the processes are, our lives become even easier.

Simplicity doesn't happen accidentally. It needs to be actively cultivated. Complexity is what happens when you aren't paying attention.

Are you a manager who pays attention to whats happening in his project? I sure hope you are :-)

Lesson No. 2: Make Project Sponsors Write Their Own Requirements

Before we begin on this topic, doesn’t the title seem impossible? Do you really think the Project Sponsors (Senior Business Managers and others high up in the corporate food-chain) will spend time writing requirements? If you arent sure, just keep thinking in the background and we will get to it pretty soon before we end this chapter.

In any country, any industry, the key reason for project failure is “Poor Requirements Definition” Though PMI recommends a clear and well defined requirements gathering phase as a mandatory part of any project’s lifecycle, in real life, that is rarely the case. In real life, teams are asked to begin development even before the preliminary or rough specs are signed-off.

The companies that are most at risk are those with poor business analysis capabilities. When specifically reporting on technology projects, such as software development, success is categorized, euphemistically, as "improbable." This result shows how difficult it is to find, identify, and define true requirements for a software project.

The software project manager usually does not have the authority or the time to find, select, and prioritize the project requirements on their own, especially since there may be several interest groups involved in the project that probably have conflicting ideas about what they envision the software will do upon completion.

It's up to the project manager to spend time with those who are funding the software project to help them define exactly what they want before the project starts. Is it more important that it is done quickly, with few bugs, or on as small a budget as possible? You can't have it all. What resources and skill sets are crucial to create the software they want? Are they making these resources available to the team?

Without serious, specific consideration of what is to be created on this project during the requirement definition phase, the success of the project is severely under question. Remember, project owners need to convey what they want this software to do, not how the programmers will go about producing that result.

Go back to the first paragraph of this post and re-read it. If you are someone with that kind of doubt, then you need to read the subsequent two paragraphs as well.

Convince the project owners that they must be involved in the process from start to finish. Solid requirements planning establishes a clear connection between the business case, project goals, and the project outcome. Otherwise, the project cannot produce the satisfactory result they are expecting.

A failed software project hurts the project owners most, since they have put up the money to fund the project and were expecting to use the software to earn back their investment.

So, if you want to be a good manager and a successful one too, try to convince your project sponsors to take part in defining/baselining the project requirements. This will eliminate undue surprises

Previous: Lesson No. 1

Lesson No. 1: Get Users Involved As Early As Possible

Imagine the Scenario – You have just completed an IT Project for a customer and when you deliver it to them, they arent satisfied. They feel it isnt exactly what they expected. Can you guess what went wrong?

The Manager probably collected the Requirements and then lost touch with the users or customers.

The secret to project success is to involve the users almost as soon as there is anything visible to show them. How much better it is to find out that there are problems with what we are developing early on, rather than after the project is complete!
Remember the PMP topics on Controlling Project Costs & Quality? Changes done to a project that is nearing its completion are far costlier than the ones that are taken up at earlier stages of the project.

Costs for changes become increasingly high the further along we are on the project schedule timeline. The time to recode, retest, and rework the immediate software, as well as to test integration with all the peripheral code involved, can delay the project substantially. And both time and cost baselines are jeopardized if a change is so major that it has to go through a lengthy Change Control Board process for approval.

As a project manager, you should get the users talking to the software developers early and often. This is exactly the reason why successful IT Projects have a team of Business Analysts who provide the interface between the users and the project team. They frequently interact with both parties and ensure that the expectations of both the team and the end users are met.

So, Hard Wire this in your brain – “Always involve Users & Customers as soon as possible in the Project Lifecycle and keep them involved throughout the life of the Project”

Index: Things a Good Project Manager Must Know