To survive, one has to adapt.  This basic rule applies to humanity, to industry and also to technology. For IT/Software startups this adaptability becomes even more relevant. Setting up an IT shop yesterday was costly. It used to be a VC funding kind of undertaking, not a personal loan kind of undertaking. Setting up offices, infrastructure, hiring people, software licenses etc. required a lot of upfront investment in time and money.

This barrier-to-entry for new businesses and technology firms is being significantly reduced by availability of “on-demand “everything (resources, infrastructure, bandwidth, capacity and so on). Unlike yesteryears, setting up a software company today can be done quickly, easily and inexpensively. Technology trends are changing and survivors will be those that are able to step out of the “Enterprise” mentality and adapt emerging trends; to not only survive but thrive!

Over the next few posts, I hope to elaborate on some of these emerging trends. Topics will include Amazon’s EC2, Google App Engine and Odesk among others.

1. Quality is not an attribute or feature that can be injected post production, it has to be built in and maintained all along the way.
2. QA does not have a say or control over the execution phase. As a result, building quality into the product is largely left up to the development team.
3. Development is not focused on assuring that quality objectives are being met at every task and phase level during execution because QA is considered to be a separate discipline.

Some development teams try to avoid these issues by inserting checks and balances in the development process in the form of design and code reviews. What has helped me in the past while managing software development projects is making quality a personal priority? Even though it is the responsibility of the QA Manager to assure that quality objectives and metrics are being met, it is completely up to the development team and manager to make sure that quality is being considered as a necessary and integral part of all development tasks. Some ways to ensure this are:

1. Understand the quality expectations of the customer and key stakeholders.
2. Make everyone in the team responsible for quality.
3. Involve key members of the QA team from the initial phases of the project to understand the quality needs, determine appropriate quality objectives and provide timely input during development.
4. Ensure that QA and Development teams are well integrated and easily accessible to each other.
5. Establish a culture of “just enough” not less or more. This applies to quality as well as development. There is such a thing as too much quality. In terms of development, providing unwanted features also known as “gold plating” is wasteful and an overhead in terms of maintenance and potential defects.
6. Establish quality friendly development processes – Prototyping, Design reviews, Code reviews, Unit testing, Continuous Integration and Constant customer involvement and feedback can all be crucial for producing a robust, quality product.

After all, the Project Manager is responsible for the successful delivery of the project.  Project success is measured not only by meeting cost, time and scope but the most important measure of project success is customer satisfaction which implies good quality. And, quality cannot be inspected in; it has to be built in.

• It was a short-term project.
• Number of stakeholders involved was very few.
• The team was very well integrated (though parts of it were off-shore)

Over the next few blogs I will share some of the principles of Lean and how I applied them to successfully manage one particular project.

Introduction
Lean is known as a paradigm that brings people, process and technology together to provide maximum value-add for the customer. Lean principles have been developed by pioneers like Taiichi Ohno and Shigeo Shingo and have been successfully used to improve Toyota’s product development system. Check out this book “The Toyota Product Development System – By James M. Morgan and Jeffrey K. Liker” if you would like to know more about it.
Lean principles have also been adopted to streamline the software development process. The following books by Mary and Tom Poppendieck are good resources if you would like to know more about the benefits of applying lean principles to software development.

• Implementing Lean Software Development
• Lean Software Development – An Agile Toolkit

Having said that, Lean paradigm offers guiding principles that are common-sense based, which can be broadly applied across a number of domains. The principles have to be then translated into appropriate practices for any particular domain including Project Management.
Here are some that I used for managing a website development project:

1. Eliminate Waste – Lean calls for continually looking at your value stream and eliminating anything that does not directly benefit the customer. With respect to keeping things simple on this blog, I will spare you the details on value stream mapping (But you can read more about about  it here: Value Stream Mapping).
    Simply put, eliminate any action/task that is wasteful and does not directly benefit your customers/stakeholders. Here’s how this principle can be applied to Project Management:

• Eliminate unwanted features:  It is traditionally considered good practice to freeze all requirements before you begin design and implementation phases of the project. Though we all know this is a close to impossible task for most projects because requirements continue to change, there is another side effect of this approach and that is Scope Bloat. Customers tend to pile on nice-to-have and maybe-needed type of features along with the necessary ones in anticipation of the requirements freeze. It is important to recognize and implement 20% of the features that provide 80% of benefits to the customer also known as the “vital few trivial many” rule. Iteratively done, this leads to a more useful and robust product in the end.
• Avoid Churn:  Churn refers to changing requirements which could result from changes in the industry, technology or the customer’s mindset. Churn happens when there is a lag in translating requirements into implementation or lag in Test-Fix cycles. This can be avoided by using the 80/20 rule to rapidly implement and deliver iterative releases to the customer. Not only does it provide value-add to the customer, it also enables quicker feedback, which can be incorporated into the next iteration. Avoiding Churn and locking in requirements may seem contradictory to another Lean principle which is “Defer Commitment” , but I will talk about in detail a little later.
• Do not adopt unnecessary processes: Several popular software development methodologies as well as the Project Management Institute stress on the importance of following processes, so it is easy for a PM to feel pressured to follow all these processes in lieu of best practices.  It is important to adopt processes that fit and benefit the project at hand and avoid processes for the sake of processes.
• Do not produce deliverables/documents/reports that nobody is going to read: Some companies are notorious for mandating documentation of everything. This only leads to wasted time and outdated documentation that often leads to confusion. Because no one reads it, there is no feedback and the document is not updated as changes occur in the future. At the same time, producing quality documents that aid or accomplish a certain task are invaluable to the success of a project. Such documents become a point of reference, a source of validation and clarity for project teams.

• Your development team needs to implement a module using technology that they have never used before.
• Your project comprises of too many independent pieces of software/technology that have to all fit together.
• Your project team is working on an application for a business domain that they are not very familiar with.

In all the above scenarios there is a potential risk of unfeasibility, discovering dependencies, constraints  or unknowns that could disrupt the order of tasks, timeline and eventually success of the project.  During the early stages of a project, when development teams are not 100% allocated a project manager can effectively allocate development team members to identify and prototype high risk modules. When used earlier during the planning phase of a project, prototyping can help:

• Reduce Risk – Any issues with new software/technology are discovered earlier. Which helps PM identify alternatives, allocate sufficient time & resources. 
•  Discover unknown unknowns – Unknown unknowns in a project are usually left to be stumbled upon along the way. If one is discovered later in the project it can lead to uncertainty, sloppy patch up and can potentially affect time, cost and quality. By prototyping early a PM can get a sneak peek into the problems that the development team would have run into further down the road.
• Uncover Dependencies –Very often in the software development process dependencies arise from external factors like availability of sample data, configuration, and environment setup. If left to be dealt with later on, these factors can cause unnecessary delays. These dependencies can be identified earlier by prototyping and the PM can plan for and handle these factors as tasks that need to be resolved first.
• Improve efficiency – Prototyping helps flush out potential problems early on, giving the project manager the ability to plan for and manage them.  E.g.  If the technology has certain limitations the PM can identify alternatives before some actions are irreversible. If the tasks have certain dependencies he can alter course before someone is stalled. Unknown unknowns can become known unknowns giving the team enough time and visibility to resolve them.  All of these make the project run more efficiently.

This does not advocate prototyping every single module that is needed for your project.  Because of  the pro-active nature in which it helps uncover potential problems, unknowns and dependencies, when used selectively and early in a project, prototyping  can be a powerful tool for Project Managers.