Friday, January 27, 2012
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 :-)
Subscribe to:
Post Comments (Atom)
© 2013 by www.getpmpcertified.blogspot.com. All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.
Followers
Popular Posts
-
So far, we have been talking in terms of projects only. There are two other terms that are closed linked with projects and project manageme...
-
In the previous chapter, we saw how to create the Project Scope Document. The next step in planning for a projects scope is to create the Wo...
-
In the previous chapter, we saw the project lifecycle in detail. In this chapter, we are going to take a look at the Project Management Kno...
-
In the previous chapter , we took a look at Expected Monetary Value or EMV Analysis . The Decision Tree Analysis is another tool/technique ...
-
In the previous chapter we learnt how to create the project human resource plan. To get resources you need to spend money (Cost) and you can...
-
In the previous chapter , we learnt the basic details about Continuous Distributions. In this chapter, we are going to take a detailed look...
-
In the previous chapter we learnt that the risk register is going to be constantly updated as we progress through the various processes in...
-
Expected Monetary Value Analysis or EMV Analysis in short is the 2nd tool and technique in the Quantitative Risk Analysis and Modeling Tech...
-
In the previous chapter, we saw that an organizations policies and culture can have a significant impact on a project. Towards the end we al...
-
In the previous chapter, we took a look at how the organizational structure can affect a project and how it affects the life of a Project Ma...
No comments:
Post a Comment