Web 2.0 is NOT a design concept

Filed under: Management — Mukul Gupta at 11:52 am on Sunday, January 27, 2008

Ever heard your clients asking , “I need a Web 2.0 Designer” or “We want a new Web 2.0 look for my website” ? I bet that if you are still in business you must already have heard of it several times and you must have done it already whether you knew about it or not.  But what does Web 2.0 design actually mean?

To a ordinary designer who can’t even explain what Web 2.0 is, it means nothing more than a good looking combination of:

1. Large Fonts in Headlines with selected words highlighted or underlined
2. Jazzy colors in High Contrasts (Apple championed it with White over Black)
3. Big Star Bursts with guarantee statements, specials offers or call-to-actions
4. Gradient and Gloss
5. Oversized boxes with bevelled borders
6. Preference to texts over images

This recipe sells wells and so there is nothing wrong with it as long as it remains in demand. Whatever happens to good old creativity, I don’t find enough reasons to complain as long as doing this makes money for our clients (and for us too!). I just imagine a day when all websites across the internet will start looking the same - it’s like they are all being run by a common CMS system.

Web 2.0 originally meant using Web as a Platform with data being as “Intel Inside”. It was a term introduced in 2004 to characterize new generation Web applications which may provide an infrastructure for more dynamic user participation, social interaction and collaboration. It never mentioned the word “design”, not in a sense of creating layouts! 

For now, let’s just label glossy layouts having star bursts and over-sized boxes as “Web 2.0 layout” because it sounds smart and no one has the time to educate the world.

Making Money with Fixed-Price Projects

Filed under: Offshore outsourcing, Management — Mukul Gupta at 2:17 pm on Tuesday, January 22, 2008

I was with a client from Australia last week and he said; “Only way to sustain a relationship is when both client and vendor are gaining from the deal”. Fixed-price contracts have the highest propensity of getting into the red and as a software services company you need to very careful (if not wary) of entering into such contracts.

When can you give a fixed quote?
Here are the rules - giving a fixed quote makes sense only when:

1. The scope of work is detailed enough to be estimated properly and you can plan the project.

2. You can meet or exceed the expectation of the client within reasonable amount of tolerance (i.e. while keeping yourself profitable)

On the other hand, you can never make money with fixed price contracts unless:

1. You have the knowledge of the business domain. This is simple to explain - if you have never built a “newsletter application” before, you will never be able to estimate it correctly. Clients cannot detail out everything and they expect the vendor to fill in the gaps, unless you have worked on the same type of applications earlier, these gaps will seem like rifts and you will blame client for not specifying everything. Remember that technical skills are not a replacement of knowledge of business domain.

2. You have the right team to do the job. Again, when you estimate something, implicitly you are assuming certain base skill-sets which you know your team possesses. At the time of execution, if a team that does not have the adequate skills or experience is assigned to the job, the project will take 10x longer.

3. You know the technology. This is no biggie! you cannot estimate R&D time beforehand. At best you can budget out for 15 days R&D but you can guarantee that at the end of two months, all unknowns will be known.

4. You have sufficient cushion. No, I am not talking about sleeping over the project! You need to have adequate slack of time, budget and profitability. If your developer estimated 20 days and you gave calendar 20 days to the client then you are doomed even before you start. Similarly, if your client’s budget is $1000 and your budget is coming to $900, its better to say goodbye to this project.

5. You factored the complexity of the project into quote. Complexity is a multiplier to the cost of the project. Forget the technical matters, you may need to change your price by upto 3x depending on the nature of the client. You need to have enough financial incentives to work with a client who is control freak and demands an update 6 times a day. Other factors to consider except technicality is communication with the client or involvement of 3rd party vendors.

Remember: Prevention is better than cure!

Ideas to protect from falling dollar value

Filed under: Management — Mukul Gupta at 3:35 pm on Thursday, January 17, 2008

Same time last year, USD 1.00 meant INR 44.6 while as of today it means something like 38.00. American Dollars lost nearly 16% of its value in a period of one year and for companies like us it may mean between 6% - 7% reduction in profits. The situation is more complex because wages continue to rise by as much as 25% per annum and unless the situation is controlled, the decline in profits will be as much as 19% - 20% for a SMB which do not have access to sophisticated techniques to managing forex.

The blazing question right now is: how an organization can protect itself from this loss? Here are some suggestions:

Increase billing rates
One of the quick fixes will be to increase your billing rates by 15% - 20%, so that you may continue to earn the same level of revenue as we used to earn earlier. Increasing the price will make you lesser attractive and for providers who compete just on price, this will spell certain death.

Increase billable hours
You may want to increase the billable hours as much as possible. Making all satirday as working days will mean that your billable hours will increase increase by 13.33% which will offset the dollar depreciation entirely. This will make your very unpopular with your employees though!

Start billing in Local Currency
You may start billing your clients in your local currency and then convert it to USD equivalent at the time of receiving payments. This is the exact opposite of what you are doing now. This approach will make you some of your clients feel uneasy, especially those who insist on fixed dollar value quotes and can’t understand what rupees mean.

Have contract level agreements
While signing the contract you can have a clause that says that if dollar value falls below a certain threshold level, the client will have to pay the difference amount.

Increase Business outside US
This is a long term solution but one that you must take a close look at. You must develop markets outside USA, so that you are not that badly affected by the dollar rates.

Reduce dependence on USD
You must invoice the clients outside USA in their local currency and not in USD. It will reduce your exposure towards dollars.

On lighter note, gold prices keep on rising. Thus, may be you can charge your clients in gold, the idea of asking for 100 gms of gold (or its $ equivalent) for a job sounds like a silver bullet solution. (Please, no noble prize for this one!)

Don’t get run over by Profits

Filed under: Management — Mukul Gupta at 1:30 pm on Wednesday, January 16, 2008

Last day, I spoke about some considerations that you must take into account while starting your business. While I am not too much a fan of grand vision and mission statements, I strongly detest the idea of being too verbose about profitability.

As a young business you should not be driven by profits but you should understand what drives your profitability. First let’s attempt to understand what profit means. According to Michael Porter profits are no more than the sum of the difference between the price that customers pay for an activity and the cost of that activity. Thus, if customer is not paying for an activity then it’s non-revenue generating overhead. As a startup, you must minimize this overhead. The best way to do this is ask - “why am I doing this?”, before you add any process or demand a new report. Don’t put the cart before the horse, profitability within the business depends on certain fundamentals and you need to:

1. Drop the image of a lone warrior and focus on building a team. You’ll need to hire and retain the best people you can find. If you don’t have good talent then you will never be able to do things as effectively and efficiently. On the other side, the cost of replacement of your best people is incalculable. If you have good people then you will navigate through anything.

2. Minimize overhead. You need to ensure that maximum efforts are put in revenue generating activities. If your best people are not spending their time productively then you are not growing as fast as you should be.

3. Be crazy about customer success. You need leave a breadcrumb of successful projects and clients. If you focus on this well then, you marketing and sales will almost be on an auto-pilot for lifetime.

4. Stop competing on price. It’s not wrong to enter a matured industry without having something special (read different) to offer to the market. But, you should never differentiate yourself on price. The reasons for this demand a separate article but I would like to hint that a differentiator should not be easily copied by competitor and price could be easily cut further by an ignorant competition.

All’s well that starts well!

Filed under: Management — Mukul Gupta at 2:51 pm on Tuesday, January 15, 2008

There is a lot of literature around about starting your own business and growing it. The problem young companies face is that it’s often a single man who has to do everything and it’s easy to loose your priorities. The age old adage - “All’s well that ends well” does not work here, it’s important to start well! Here is a small list of things that if you can follow:

Keep customer satisfaction above everything else

Service business runs on referrals and reference checks. While, there are plenty of blog posts around that talk about getting even with customers or firing them, I recommend you abstain from them for a while and rather choose your customers carefully and then do everything to keep them happy. Remember that you’ll need projects that you can showcase in your portfolio and people who can give you five star feedback.

Build your management team

You will not be able to grow if you have to everything yourself. You need a line of leadership within your organization that can take care of entire functions and handle tough issues. A start-up is usually starved of cash and hence do get too crazy about hiring management grads. Instead hire people who are keen to learn, have a fire in their belly and are ready to grow with you. Assign them responsibilities early-on and let them do their jobs.

Invest in Tools and Processes

It is much easy to adopt a tool and process in a 5 people company than in a 50 people company. Thus, it is important that you sit with your team and employ tools in the areas on project management and establish key processes atleast in the areas like Project life cycle, Accounts & Invoicing and HR. There is plenty of free stuff in the market and you will realize later that your PM tool has become a goldmine of information and even a platform for information sharing.

Specialize

Don’t fall into the trap of trying to pick of all sort of projects regardless of price and technology. This garbage collector approach will put you in a death spiral from which you will not be able to recover from later. In the initial days it is important that you specialize in only certain type of projects. It will be easier to manage! Try looking for simmilar type of projects as the code reuse can boost your profitability as well as you can surprise the customer with a quick delivery. You must have proper management body in place before you undertake any diversification initiative.

Save Cost

Don’t run into renting the most plush offices that overlooks the ocean and buy expensive furniture with Aeron chairs. Remember you are startup and you are not competing with IBM. Keeping your ego in check and that will help you control your expenses.

I don’t remember where I read it but I must quote and say is that being successful is not about doing things exceptionally well but it’s about making lesser mistakes.  

Web Commuting - Walking the Talk

Filed under: Offshore outsourcing, Management — Mukul Gupta at 1:39 pm on Monday, January 14, 2008

‘Web Commuting” is increasingly becoming omnipresent. A Citrix study showed that this is becoming increasing common amongst Americans. It read and I quote:

This survey, conducted by the polling company, inc., found that 23 percent of American workers and 41 percent of small business owners regularly work from home or another offsite location

Our own organization also launched a W@H (Work at home) program which allowed employees doing certain type of work to work from thier homes in case they are unable to come to office for any reason. This implies one thing for sure that with time, we will see less of our employees face-to-face.

This trend makes the importance of proper communication even more important. According to experts, our non-verbal language communicates about 50% of what we really mean (voice tonality contributes 38%) while words themselves contribute a mere 7%. Thus, talking to your employee only via emails, documents or instant messenger means utilizing only about 7% of communication potential and getting only 7% information. Thus, If you not willing to travel at least once a year or devote time to provide constant feedback then it is not going to work for you. Our W@H model has matured to a level where we have employees hired for web commuting only. We see the benefits, but it has not come without time and investment. 

Web Commuting can deliver outstanding cost benefits, adding the dimension of “outsourcing” makes it more lucrative. However, you must carefully plan your business processes to see if it fits your need and when you are ready, involve experts who can walk their talks 

Frankly, I feel that outsourcing companies that sell “offshore staffing” as a service whereas, they do not allow remote working to their own employees, are hypocrites. They sell what they don’t believe in!

Managing Talent

Filed under: HRD, Management — Mukul Gupta at 10:44 am on Wednesday, January 2, 2008

What does Jack Welch (The legendary CEO of GE) and McKinsey have in common when it comes to managing talent? Both of them seem to agree on the same thing when it comes to managing talent within an organization. In order to build a great company you need to employ great people.

What actually are A , B and C graders ?
“A” grade employees are people that deliver beyond what they are expected to deliver. Look at your best designer, best programmer, best sales guy, best support technician or, look at the best people with the same level (i.e. having same designation), your best manager, your best project lead. - they are the “A” graders within your company. The people whom you truly consider your assets!

“B” grade employee are people who are consistent performers. They don’t do exceptional things but they are fairly consistent at what they are doing. According to Jack Welch - “They are on the fence”

“C” grade employees are poor performers who either cannot deliver results or require too much pushing.

Why can’t you hire “A” Grader directly?
The problem is that there is no sure shot technique that will guarantee that you will have all the “A” class guys working for you. There are not many of them around! Even if you can come up with an objective shortlisting process that can help identify a super-performer from an average-performer, meeting the numbers will be quite a challenge - specially if your company is growing at 100% every year. If you think that everybody who works for you is an “A” grade gut then you have simply not raised the bar high enough.

The good news is that hiring “B” grade performers is not that difficult and as it turns out, it is a better strategy too. There are following possibilities with a guy who is at “B” grade:

  1. He will turn out to be a “A” grader (Tiger within Sheep’s skin!)
  2. They will remain “B” graders
  3. They will actually turn out to be “C” graders

There is a real competition out there for hiring talent. McKinsey says that this “war for talent” requires a new way of thinking for attracting and retaining quality talent:

  The Old Way The New Way
Talent Mindset HR is responsible for people management. All managers – starting with the CEO – are accountable for strengthening their talent pool.
Employee Value Proposition We provide good pay and benefits. We shape our company, even our strategy, to appeal to talented people.
Recruiting Recruiting is like purchasing. Recruiting is like marketing.
Growing Leaders We think development happens in training programs. We fuel development through stretch jobs, coaching, and mentoring.
Differentiation We treat everyone the same, and like to think that everyone is equally capable. We affirm all our people, but invest differentially in our A, B, and C player

So you are in a safe position as long as you have a process to recognize and reward the “A” grade people, attract, train and upgrade the “B” grade people and most importantly, identify and get rid of “C” grade employees.

Why getting rid of “C” grade people is important?
There are a lot of reasons why you should get rid of poor performers:

1. You stand for what you tolerate. If you tolerate incompetence then you and your organization stands for it.

2. There is lot of effort required in converting “C” graders to “B” grade. At the same time remember that your “A” graders and “B” graders are spending their time on “C” graders. It’s like throwing an olympic swimmer into a pool with weights tied to his waist and then expecting him to win the race. I firmly believe that the results will be much better if a “A” grade employee spends time on “B” grade than on “C” grade.

How to avoid hiring “C” graders?

I think “C” graders are terrible at recruiting. If you believe, that a person is below average (either within the organization or amongst peers) then that worst thing that you can do is let them hire other employees. So, you should only allow your best and brightest people to select future employees of the organization. Remember, no one can hire someone better than himself. So, while “A” graders will hire “B” graders, “B” and “C” graders will hire even more “C” graders.

Let’s begin the new year by cleaning up some deadwood. Shall we!?

Staffing across the Project Lifecycle

Filed under: Offshore outsourcing, CMMi, Management — Mukul Gupta at 5:22 pm on Monday, December 31, 2007

I have already discussed how the progress of a project looks slow during the initiation and closing phases and what are the reasons behind that. Today, my point is to discuss how the staffing changes during the project phases. First, let’s understand what staffing means. For our purpose, we will assume that staffing means:

1. Personnel required for a project OR,
2. Utilization of personnel across the project lifecycle.

While the first definition means the physical quantity of people who are working on the project, the second definition means the % of time spent on project activities each person days (this is especially valid in case of small, single person projects that we do). If we plot in graph, the staffing of a project with respect to time, we will see something like this:

 

 

 

 

 

 

 

 

 

 

 

 

Let’s attempt to understand why this happens:

1. Each project goes through a cycle of Requirements, Product Design, Detailed Design, Coding and Unit Testing, Integration and System Test. For a typical 100 person-days project here is a breakup of effort that you may expect is 10% for Requirements, 20% for Design activities, 50% for Coding and 20% for Integration and System Testing. These activities can be sequenced or iterative and in either case, not all effort is spent at once. Since all effort is not spent at once, the resources are allocated in proportion to requirement i.e. effort is pulled based on the demands of the project.

2. The important thing to understand here that Allocation and Utilization may not mean the same thing. Even if someone has been allocated full-time/exclusively to your project, they may not be able to be utilized 100% on it. For instance, during the initial stages, only one person is required to do requirements analysis while during coding several developers may be allocated to the project. There is no point in allocating the full team at the time of project initiation itself.

Four Type of Causes

Filed under: Management — Mukul Gupta at 1:25 pm on Wednesday, December 26, 2007

Aristotle was one of the greatest philosophers who ever lived. I think his contribution to both science and philosophy is enormous. He described that there are four types of “causes” i.e. Material, Formal, Efficient and Final. Let me describe these causes in the following way: Let’s assume that a programmer has made a software using PHP.

In the above example, PHP is the material cause because this forms the material from which the software has been made. The Formal cause is the essence or the need for fulfilling which the software has been created. The efficient cause is the act of programmer keying in PHP codes into the computer because this act actually results in the software to be created. Otherwise, the programmer can look all day at the screen and there will no software at the end of the day. The final cause of the software is the programmer itself and what he had in mind about the essence of the software.

Why is this important to know?

When I spent some time thinking about it, I realized that the impact is very deep. For one thing, causes leads to effects. The final cause of the software is the programmer’s interpretation (or misinterpretations). Thus, the final cause may end up producing a software which is very different from the formal cause. What if there is unity between the final cause and formal cause but the material cause is insufficient i.e. the technology used to produce the software is incapable of producing the desired application?

Thus in order to meet the formal cause of any software application it is important that:

  • The technology (or material cause) should be available or acquirable.
  • The process and resources (efficient cause) should be available or acquirable.
  • The understanding of the formal cause should be shared across the team members.

Project Progress during Starting and Closing Phases

Filed under: CMMi, Management — Mukul Gupta at 1:09 pm on Friday, December 21, 2007

I think 80% of the project work is completed in 40% of the total time while it’s the remaining 20% that takes 60% of the time. Those of you who ever had to manage a project will notice that the it starts very slow and then it picks up speed and you see a lot of progress being made everyday but suddenly towards the end it slows down again and you feel that your team has lost the zest or they are slacking behind. But is this not expected ?

if you plot the progress of the project (% of feature completed with time), you will see it takes up a S-curve as below:

S-Curve 

 

 

 

 

 

 

 

 

 

 

Let me explain why initiation and closing is slow.

During Initiation

Initiation refers to the starting phase of the project when you receive the notification that the project has started. It needs to be understood that unlike race-course horses, developers cannot dash out the gate at full throttle towards the finish line. They have just been allocated and they don’t even know what the project is all about. Here are some reasons which will slow down the progress during the starting phase:

Team Establishment

This is not about allocation of people. The team goes through a whole stage of Forming-Storming-Norming-Performing (Bruce Tuckman). This duration of this cycle depends on both the size of the team as well as diversity of domains/specialization within the project.

Ambiguity in Requirements

From no documentation to hundreds of pages of requirements, but I am yet to see a requirement document that is understood exactly in the same way by all people. There are multiple round of discussion between the team members and with the client during which the progress seems frozen.

Tools and Environment

In certain cases the project is dependent on tools and environment which is hard to duplicate in our development environment. I once remember a search engine portal project that we were doing in which our job was to make some enhancements. The current system extensively based on XPATH queries and we lost 10 days in just setting up the system on our server. In another project we are doing, the client had four different versions of the same application and the application called files (PHP includes) from multiple versions. We had to set up a team of 3 people for 7 days just to clean up the code and set it up on our servers.

During Closing

Closing is the abyss between when a developer says the job is complete and when you say that the job is complete. Here is what happens:

Product Integration

Often we have to wait for days (or weeks) for simple things like Payment Gateway info, SSL Certificate or information from 3rd party vendors on proprietory systems (web services) that the system must be intergrated with. Sometimes, server does not supports parts of codes that we have written and upgradation of server or rework of code is required.

Note: CMMI required all integration requirements and environment to be planned earlier but still, if your hosting company responds to request within 5 days then what are we supposed to do?

Defects

As more features are added into the system, more bugs are also introduced. As the bug database takes a life of its own, there is a tendency to increase the mix of bugs to new client-valued functions being coded. The result is that the overall speed of the team is maintained but an increasing percentage of the effort is devoted toward fixing bugs or adding “bells and whistles”

Enhancements

Buy enhancement I am referring to all the things a developer had to do which he did not knew he will have to do when he started the project. This mostly comes in the form of - “Of course it was supposed to be there!” and with some luck we will be able to point back to requirement document and say “nope!”. The problem is that time is spent in these negotiations and discussions which would rather be spent on stabilizing the current set of features that the product already has.

At the end, I remember what one client told me - “Project is like painting the wall - it’s the corners that take most of the time!”

Next Page »