The 3 C’s of a Successful Project

 It is a well known fact among software professionals that a majority of software projects fail. In fact, this phenomenon is not limited to software projects. If we define “success” of a project as “a state when it meets all the stated objectives and requirements and is completed within the time and budget, without compromising quality” it is easy to spot failures in non-software projects too.

It is interesting to note that the size of the project and therefore the budget and timelines have no bearing on the success of the project.

There are several analyses and theories on why project fails and there are as many remedies too. All of them are valid and useful in some ways and are suitable to a given project.

Here is an attempt to define the three most significant contributors to a successful project - the three C’s of a successful project.

1.     Clarity

Clarity of requirements is the most essential ingredient of a successful project. Often the requirements can be complex and are not easily comprehensible. Detailed analysis, discussions and decision making are essential for the clarity to emerge. The saying “assumption is the mother of all screw ups” is worth remembering all the time. While assumptions are essential in situations where there is no way to find the right answer, it is very important have consensus among the stake holders on what to assume.

No programming language offers syntax to say “not sure”.  If you are not sure, then you need to assume and proceed. When building a house, you can’t say “I’m not sure if I want a window here”. You may assume that you will need a window in the future and give provision for the same. While decisions such as this can be taken even when the work is in progress, some decision will have greater impact on the project. For example, the number of floors your house will have is a decision that needs to be taken before the work starts. There are similar decisions in software projects which when not taken at the right time will have enormous cost and time implications.

In software projects, the impact of lack of clarity is significantly high due to the intangible nature. It is easy to appreciate how a physical product takes shape and therefore the impact of changes. A non-technical user can seldom appreciate the impact of a change in a software project. This makes it all the more important to have absolute clarity of requirements including intelligent, unanimous assumptions.

Clarity is the “What” of a project. It is the answer to the question “what do you want to build?” Do not start if you are not clear. Don’t step into a muddy river, lest you are most likely to drown.

2.     Capability

Once you have the clarity of what to build, you should have the capability to build it. Capability refers to the skills required to build something. Capability is essential not just for execution but also for the Clarity to emerge. Only a skilled architect can ask relevant questions so that the user is provoked to think and crystallize the requirements.  When Capability exists, the right questions are asked. When right questions are asked, answers are found. When answers can’t be found, intelligent assumptions are made. With this, Clarity emerges.

It is a capability by itself to understand what capabilities are required to execute a project. It is important to discover the requirements that would need some research and learning during execution. These requirements would need to be addressed at the beginning of the project, so that the answers are found early.  High levels of skills are essential to produce quality results.

Capability is the “How” of the project. It is the answer to the question “How do I do this?” Do not start if you don’t have the capability. Identify your weaknesses and get the required support.

3.     Commitment

Capability without commitment will not yield results. Half-hearted attempt by members of the project team can spread negative energy in the team. This will cause imbalance and friction in the team and will consume a lot of energy in utterly unproductive activities such as rework, resolution of conflicts and lead to frustration and fatigue.

Quality is the major causality when there is lack of commitment. A half-hearted attempt can never produce quality. This is true for any profession. Great works of art are produced by artists of utmost Commitment. Magnificent buildings are built by engineers of enduring Commitment. People who take a casual approach to their work would stagnate and would be the first to perish when adversities strike.

Commitment is the “Why” of the project. It is the manifestation of the answer to the question “Why am I doing this?” Do not start if you are not committed. Because, commitment to what you do is the very essence of your being. 

My Take-away from this World Cup Victory

I don’t understand the technicalities of Cricket beyond what is required to enjoy the game. However, I could sense Indian team’s victory in the finals right in the early stages of their batting. It is not due to my ability to analyze the game, but due to what I could see in the way the players carried themselves in the field. I could see this written all over them: “we are here to win this world cup. We refuse to be bowled out tonight.”  I’m sure, they would have chased even a 350 that night!

Analysts have observed that India and Sri Lanka were evenly placed, in skills. But, skills have no value unless each player plays to his potential. This would happen only when one is in his highest spirit. Every player in the Indian team was in his highest spirit.

In my observation, there were three key qualities that lifted their spirit and helped them to perform the way they did. And this was my take-away from this great victory.

1.      Mental Make-up

The team displayed the extremely-hard-to-acquire ability to remain cool and focused under pressure. The calmness of mind brought out the best of their judgmental abilities. This helped them avoid playing wrong shots and preserve their wickets.

2.      Sense of Responsibility

Each player had a responsibility to fulfill. No matter what his playing style was or what he was comfortable doing, there was a responsibility to fulfill in the given situation. The ability to adapt to the situation and fulfill the responsibility kept the scoreboard ticking and the “required run rate” under control.

3.      Team Cohesiveness

This, perhaps, is the single most important factor in realizing one’s potential while playing in a team. The players were egoless, supported one another well and showed respect to the teammates irrespective of seniority and position. They all had only one goal to achieve and equal roles to play. This helped them to keep their mind uncluttered and stay focused on the job.

Applying this Take-away in Our Professions

These qualities are applicable to any profession where people work as a team. They would raise the spirit of the people and help them perform to their potential. While the first two qualities can be developed at individual level, “Team Cohesiveness” needs to be facilitated by the team leaders and organizations through their work culture and value systems. And this is what the Indian team’s captain and the management should be credited for!

Please leave your comments below. If you like this blog, please follow.

 

"Minimum Viable Product” at TiEcon Chennai

The highly successful TiEcon Chennai of this year hosted two “unconference” style sessions one of which was on building products with bare-minimum feature functions and taking them to the market. The participants shared their experiences which gave great insights into implementing this strategy. Here, I summarize the discussions with the important points that emerged in the discussions.

The Strategy

In the highly competitive markets of today, time-to-market is becoming more and more critical and so is the need to build products that incorporate the cutting edge technologies. It is also important to obtain user feedback early and use them to quickly enhance and perfect the product. The strategy is to develop products with bare-minimum feature functions and take them to the market. While reducing the time-to-market, this approach provides several other benefits.

The strategy is best applied in software products where it is far easier to distribute updates and upgrades. However, it is possible to apply the same strategy to physical products as well but with a different approach.

In the web applications world, the strategy is called “Minimum Viable Product” (MVP), a term that I would use in this article to refer to the topic in discussion.

Early User Feedback

No market research and analysis can substitute feedback from real users. It is important to get the real user feedback as early as possible so as to make necessary corrections. However, the problem is that a real user needs a real product to use! Building a minimum viable product that is ready to use offers the perfect solution.

Fail Cheaply

One of the most important advantages of the MVP approach is that it allows the entrepreneur to “fail cheaply”. Experiencing failure with minimum loss of effort and investment allows the entrepreneur to recover quickly and shift focus from one idea to another.

Failing cheaply has psychological advantages too. The psychological impact from failure of a high investment, high expectation project is far greater than from failure of a low investment low expectation project. This is very important because, the key strength of an entrepreneur is his / her ability to recover from failures.

The “minimum viable”

So, what is the “minimum viable” or “bare-minimum”? It is the feature functions that address the most important customer pain areas. You are expecting the user to use a product that has limited set of capabilities. Therefore, it should have compelling features which the user will find attractive enough to experiment.

In a market where there are already existing products, MVP may not be an option at all. However, products such as Google Docs which, in a sense cater to the already existing “office automation” market and competes with matured products like Microsoft Office, can still be candidates for MVP approach. Google launched Google Docs with bare-minimum feature functions and is continuously evolving. The most compelling and unique feature of Google Docs is online collaborative editing beyond corporate firewalls which has attracted millions of users.

The “prototype” approach

MVP can be applied to physical products in the form of “prototypes”. A prototype is a working model of a concept / idea that has all the important features functions for validating the concept / idea. “prototyping” is a widely used approach in automobile industry.

Prototypes are normally validated by a closed / known set of users. These users would use the prototype to do real things in real-time. Prototyping allows perfecting the product and making it mass market ready before investing in the expensive production infrastructure.

Parallel Development 

It is important to continue product development in a parallel track while the MVP is being tested by the users. MVP is not the complete product but only a stage in product development and needs continuous enhancements to make it the complete product. Waiting for all the feedback to emerge before continuing development can prove costly as you are likely to loose considerable amount of time in the process. A better approach would be to continue with the development and make necessary changes / corrections as and when user feedback is received. This way, you would have the complete product ready very shortly after the all the user feedback is received.

Product Beta

The “Beta” version of a product is complete in its feature functions but may still contain hidden defects. Launching products in “Beta” is becoming increasingly popular in the web-application world. The reasons for this are mainly (a) in a software product, finding those minor defects is extremely time-consuming and almost impossible by using standard testing methods; (b) In web-applications, it is relatively easy to incorporate changes and extremely simple to distribute them (due to its “hosted” nature.)

It is important not to confuse Beta product with MVP. Unlike MVP, beta product is a fully developed product, one step away from release.

Building MVP using Open Source platforms

For web applications, it is a great idea to build the MVP using open-source platforms. At UniMity Solutions, we build our MVPs and prototypes on Drupal platform. In our case, we continue to use Drupal to develop the complete product. However, if you need to use other more general purpose platforms / frameworks, it is still advisable to start with platforms like Drupal as it offers several out-of-the-box methods to build applications.

To Charge, or not to Charge!

Should you charge the customer for your MVP? In almost all cases, asking to pay only makes it difficult to get the user use your product. Remember, your primary objective is to collect feedback on your product and not sell it. However, if you think that you MVP offers a perceivable value to the customer, you may consider charging them.

Please leave you comments below. If you like this blog, please follow.

Evaluating Drupal Modules

Any serious Drupal Developer would admit that one of the most challenging tasks in Drupal development is to identify, evaluate and adopt contributed modules. This is so, for the following reasons:

1. Many of the contributed modules are written by developers, with specific Requirements in mind which need not be exactly matching you requirements
2. There are many modules doing the same task but with different approaches
3. The code quality is unknown until tested

It is therefore important to take a systematic approach to evaluation of modules in order to derive the best value out of them.

In my last blog, I wrote about the key questions to ask while evaluating a Drupal module. The questions are:

1. Is the module well maintained?
2. How much of the requirements does it cover?
3. What is the effort to customize / add / remove features?
4. Does its design employ Drupal’s best practices for writing modules?
5. Is the code well commented and easy to understand?

It is most likely that you don’t get positive answers to all of these questions. How the answers affect your decision would depend on a number of things including:

1. The volume of traffic the sites is expected to handle
2. Your Drupal skills and ability to maintain modules
3. Time and resources available

Module Maintenance

A well maintained module with a lot of community support can be safely adopted. Following is the screen garb of the Webform module taken form the Drupal website.

As you can see there is continuous development and maintenance happening for this module and is current with Drupal’s latest release. The Maintenance Status says “Actively Maintained”.

Another indicator is usage statistics. While this need not provide the complete picture, it is a good indication of adoptability of the module. Here’s a screen grab of usage statistics for Webform module:

As you can see, there is a large and growing user base making it very safe to adopt.

It is also important to take a look at what are the pending issues for the modules and have a good understanding of them. If some of the pending issues come in the way of using the modules, consider fixing them and sharing them with the community.

Requirements Coverage

The best way to understand how much of your requirements would be met by the module is to install it and try it out. Some modules provide screen shots and demo sites with which you can experience the functionalities.

If you don’t have a development team capable of customizing modules then you don’t have many options. Pick up the module that best suites your requirements and use it.

There are modules which can be used as a basic framework to build specific functionalities on top of it. Organic Groups (OG) module is an example. Many people use OG to create and manage user groups and build custom functionalities on top of it.

Many of the popular Drupal modules provide well structured interface functions / APIs for extending the module’s functionalities. Such modules can be easily extended without worrying about how the code is written and the possibility of breaking upgradeability. This very useful if you wish to use the module as a basic framework to build specific functionalities.

Effort for Customization

If you have the skills and resources then you can compare the effort of developing a module yourself with customizing an existing module. Module customization can involve both extending functionalities and equally importantly, removing unwanted functionalities – which can be a very hard thing to do. Therefore, careful analysis of the design is required to assess the effort requirement.

Too much customization required? You are very likely to break the upgradeability of the module. Well maintained modules receive regular patches covering various fixes including the ones related to security and functionality enhancements. Over customized code is very likely to break during patch updates and upgrades. However, if you have the skills and resources to maintain your own code then you can still make use of code blocks from the module saving some development time and effort. Again, if you think what you are building is generic in nature, consider giving it back to the community.

Employment of Best Practices

Drupal website has a detailed guide to module development . While certain methods and guidelines must be followed by all modules, others are ‘best practices’ and therefore optional. For example, a module can by-pass Drupal’s APIs to directly query or update database tables. Similarly, a module can use custom code for database access rather than using Drupal’s API. While there could be valid reasons why some of the guidelines are not followed, employing best practices will make it more maintainable and easy to understand.

Coding Standards

Code written by experienced developers are always well structured and easy to comprehend. If you plan to customize or maintain the module then make sure that the code can be easily understood. A well organized code is also an indication of bug-free code.

Can’t find it? Build it.

With ever growing base of contributed modules, it is very likely that you will find a module that meets your requirements. The very reason you are looking for a module is because, your requirement is generic in nature. Therefore, in case you don’t find the module you are looking for, build it as a generic module and contribute to the community. And when you build it, ensure that it has all the qualities that you were looking for in a module!

Please leave you comments below. If you like this blog, please follow.