Friday, May 03, 2013

Fallacy of % allocation to multiple projects


I have seen in multiple situations that managers are hesitant about committing their resources to multiple projects. Even if they commit to multiple projects, they (managers and individual resources) go overboard with percent allocation to multiple projects. E.g. if someone is allocated 80% to project A and 20% to project B, people religiously put aside 8 hrs in a week for project B, and they push back on project A if it needed more than 32 hours in that week. Some people put aside few hours every day or one day in a week for project B. These models are ridiculously impractical, and impact all projects. The funniest thing is that 8 hrs and 32 hrs are approximations and some people (not all) use it conveniently based on their preferences. I have not seen anyone literally clocking their time, and it’s not practical either.

It’s expensive to dedicate resources for a single project. We need to come up with a better way to deal with multiple projects situation. The goal is to ensure that all projects are successful.

Let me clarify something. % allocation is mainly used for planning your budgets for accounting needs. We should look at allocation as a decision making framework used to make a right choices. E.g. developers use prioritization guidelines to pick up tasks from project A and project B. Leadership and management team needs to agree on what’s really important for all projects and provide guidance to individuals. Sometimes we need to use common sense to move around schedules to make both projects successful.

Your organization culture and culture within team plays an important role. The right culture will empower individuals to make choices which are in line with business goals. This way we will not spend too much time on analyzing % allocations.   

Sunday, June 26, 2011

Did communication technologies improve software project duration

I feel that software projects are taking same amount of time compared to what they used to take 12-13 years ago. Please note that I am making apples to apples comparison considering technology, process and people maturity. Please do not confuse this comparison using "time to market" dimension. e.g. People used to spend 6-9 months to develop reports. Today it may be taking few weeks. I am not comparing on that ground. I am comparing based on complexity of the work. I am considering complexity as a combination of technology, process, and people.

This means projects with very matured technology components are taking same amount of time compared to what they used to take 12 years ago. Projects using new technology are also taking same amount of time compared to what they used to take 12 years ago. This comparison also applies to process maturity as well. Although we did not have Agile 12 years ago, some projects were using this process without labeling it as Scrum or XP. I feel that today's Agile projects and Agile like projects 12 years ago are taking almost same amount of time for completion. This story is also true for People.

Did innovations in communication methods really help project duration? In last decade, we have seen Video conferencing, IM on any device, hi-speed Internets, blogs, social networking. These communications also enabled 24/7 work model with outsourcing across the globe. We think that we can achieve something very quickly but we quickly realize that it was an illusion.

I think innovations in communication helped us a lot but they also introduced lot of "noisy" information to our life. A "noisy" information is a piece of information that does not add any value to the project but sometimes distracts people. A lot of information is available constantly to project teams. Communication technologies have enabled constant status reporting in all pockets of the project. We can spot any person at any time to ask a question or seek information. However continuous status reporting becomes an information spam and does not help us in concrete decision making. The volume and speed of "noisy" information have gone up significantly in last 12 years. We get distracted and spend too much time in processing that information.

If we try our parent's office lifestyle and use technology then also we will accomplish quality results more efficiently and peacefully. E.g. If we work during office hours only and do not check emails and make phone calls during non-working hours then we will not produce and consume noisy information. If you know people are available for limited amount of time then we will be careful in terms of producing and receiving information.

In a nutshell, we should not allow new technologies to create a noise in our life.

Thursday, September 14, 2006

I met Sabeer Bhatia, co-founder of Hotmail.

I could meet Sabeer Bhatia today. He came to our Carnegie Mellon campus as a guest speaker. I was very impressed and motivate by his speech. He talked about hotmail story and his other startup ventures. Hotmail was a big success. The later startups were not as successful. All this information is available on web so I won't spend time on it.

I just wanted to share one thing, which I took from his speech. In his entrepreneur career there were ups and downs but there was one thing, which was constant. His tremendous passion towards whatever he is doing.

I guess every entrepreneur requires this passion. Passion helps entrepreneur to face hurdles in day-to-day business. Passion helps to retain employees since employer’s passion also influences them. Passion drives you successfully through downturn.

Now the question is: How people like Sabeer are always so passionate. I am not sure.
What are your thoughts on this? Please post your comments.

Monday, September 04, 2006

Web 2.0

What is Web 2.0

There are several definitions floating around Web2.0. The most simplistic definition would be second generation of Internet based services.

The first generation was during dot com boom where the major emphasis was to publish your content on the web and look for ways to find more number of subscribers. The second generation is all about easy and to certain extent real time collaboration. You do not need a heavy investment to publish your content. You do not need heavy investment to reach millions of users. The technology enables you to publish your opinions, demonstrate your strengths and get feedback from other Internet users.

Web2.0 is a combination of technology, business trend and newer approach of using an Internet.

Is web2.0 a bubble?

I do not think so. Bubble is always related with Finance. Finance bubble occurs in two simple steps: 1. People invest too much due to some fortune telling or speculation and 2. Withdraw money all of a sudden because of another speculation. Today all of us are very careful investors since we saw the dot com burst just a few years ago. People will invest in companies who solve customer’s problems with the help of technology rather than just provide a technology.

What problems web2.0 can solve?

I can think of few areas.
1. Web 2.0 is a great media for people having great skills but unable to demonstrate in front of mass audience because of lack of funding or unavailability of platform. E.g. a person living in third world country has great product ideas then it’s easy for him/her to share through wikis.
2. Offshore software development model can utilize web2.0 for effective communication.
3. Offshore manufacturing models can utilize it for collaboration with different companies in supply chain. E.g. Design partners, tooling partners, suppliers, contract manufacturers, OEMS can collaborate for new product launching.

There might be more than these applications. The companies in this space will be successful only if they solve the real customer problems.


How Web2.0 can generate money?

I think the revenue generation is through effective advertisement. I feel that Internet is major competitor of television. In few years advertisement on Internet will be more effective than advertisements on television.

Monday, June 26, 2006

Work models used in systems and requirements

Five different models provide five perspectives on how work is done. These are described in the following table.


Flow Model
=========


Usage: To capture communication and coordination between people and organization.


Description: This model offers a bird’s-eye view of the organization, showing people and their responsibilities, the communication path between the people independent of time, and the things to be communicated—either tangible artifacts or intangible coordination. It’s appropriate to use it for building a product for many customers. It helps to get most appropriate flow at abstract level which is useful for many customers. This helps to create a product for multiple industry segments. (E.g. ERP systems)


Sequence Model
============


Usage: To capture detailed steps performed to accomplish a task.

Description: The sequence model represents the steps by which work is done, the triggers that kick off a set of steps, and the customer intents that are being accomplished. This model starts with overall intent of the sequence and the trigger that initiates it. Then it lists each step in order. Steps that can cause problems are labeled with lightning bolt. This model is appropriate for building product for multiple customers to identify common intents and common steps.

Artifact Model
==========

Usage: To find out how artifacts are used and structured in doing the work.

Description: Artifacts are tangible things that people create or use to help them get their work done. Artifacts gives insight into following: Which information is important to user, How the information is used, How to organize information according to user needs.
In muli-customer product, it might not be very useful to study this model for every customer. Artifact model for one or two representative customers is good enough for design.

Cultural Model
===========

Usage: To capture culture and policy.

Description: Culture and policies of an organization typically influence how work is carried out. Lack of understanding of culture and policies might produce a system which is not acceptable or useful to customers. This model helps us to find influencers (people/organizations/groups) and the extent to which they influence the work. This in turn helps to design a system appropriate for a culture. This is useful in developing product for multiple customers to find out the culture at abstract level. Sometimes, nature of process drives a culture and it can be similar across organizations.

Physical Model
===========

Usage: Demonstrates the physical environment as it supports the work.

Description: Physical model reveals design constraints. The model represents how the work is structured at individual workplace and site. This model gives more insight into organization of environment used to carrying out a work. This model is not equally important for multiple customer environments since the physical model might be entirely different for each customer.




Reference :
Contextual design by Alen Cooper
and
My experience with these work models

Vision Statement in software project

Vision document describes application in general terms, description of target market, the system users and their profile, and application features. In summary, vision document is a concise description of everything which is most important about product and application.

In software development, development teams get grouped based on either similar technology or similar features. E.g. UI group, backend group, Java developers, Billing System team etc. As we go along, each group’s thinking becomes narrow and gets restricted to their own domain. These teams initially interact with marketing very closely but this interaction becomes infrequent during development cycle. The decision making during development is completely influenced by groups who have very good articulators. This type of development environment is not appropriate since it is not customer focused. Vision document helps to alleviate this problem if visited frequently during development cycle. This document connects customers, management team, marketing, development team, and project managers and helps them to come to a same play ground. It helps teams to understand the end customers, their bottom line, users who are going to use the software. With this understanding, decision making and priorities revolve around customers and their problems.

Vision statement enables team to produce a product which is easily acceptable by customers. Customers get features which they consider important because those features solve their business problems.

Sunday, May 28, 2006

Use Cases

What is a use case?

According to Alistair Cockburn, use case captures a contract between stakeholders of a system about its behavior.

Why use cases are important?

Use cases depict all possible interaction of users with the software system. In any project, capturing use cases is a useful step. It helps us to think in direction of end user’s perspective. We tend to capture significant exceptions conditions in requirements stage itself. It helps development team to understand the system from user perspective. Use case also helps project managers to set milestones and come up with estimations.

User interaction might be very small percentage of total requirements, but all the requirements revolves around user interaction. Consider user interaction as a hub of requirement wheel and the spokes are resulting requirements in all direction. If we can capture most of the user interactions then we can assume that we have captured most of all requirements.

Use cases are not perfect. We write use cases based on current understanding of system and domain knowledge. In all software projects teams’ understanding of domain, requirements and technology improves as time passes. It’s a natural process. Some use cases might sound stupid towards the end of the project, but you need to appreciate that those stupid use cases lead you towards right path. We need to strive to make use cases sufficient.

Reference
I would recommend a book called “Writing Effective Use Cases” by Alistair Cockburn. Author discusses various use cases formats and their applicability in different situations.

Friday, May 19, 2006

Contextual design

Any successful system improves its users’ work practice. The improvement means increase in efficiency and accuracy. One should be able to deliver in less amount of time without any errors. Technology in software really does not matter. People decide to use jazzy user interfaces because they look good during demo and they look “cool” to your developers. But, if that extra graphics is killing the performance and not adding any convenience to end users then it’s incorrect technology to use. If particular software is going to improve the system then it will get revealed during design phase itself. If we are not sure about it after completing high level design then do not start coding. It’s time to revisit your design.

Contextual design as described by Hugh Beyer and Karen Holtzblatt promises successful software. The process of contextual design drives work redesign if required. Work redesign brings the designers together to discuss the consolidated data and how technology can improve the work. This focuses the conversation on how technology helps people to get their jobs done, rather than on what could be done with technology without considering the impact on people’s real lives.

For more details on contextual design, I would recommend you to go through book called “Contextual design – Beyer/ Holtzblatt”.

This book is available on Amazon.com
http://www.amazon.com/gp/product/1558604111/qid=1148032519/sr=2-1/ref=pd_bbs_b_2_1/102-4335525-3001724?s=books&v=glance&n=283155