Project Charter

Project charter can be considered as the document which describes a project comprehensively. Project charter identifies the need for a project to exist and to be executed. Through project charter the sponsors of the project initiate it. Through project charter, the sponsors authorize the use of organizational resources for the successful execution of the project. The project manager may or may not have been identified till the Project Charter is defined but it outlines the authority to be bestowed on the Project Manager. Also Project charter outlines the outcome that needs to be achieved and the criteria that will define the success of the project.

Expert Judgement

The success of a project depends on taking the right direction and that requires input from people who have specialized knowledge in the domain in which the project is being undertaken. Also, you don't want to reinvent the wheel if the knowledge can be accessed and used by engaging an expert.

The key is to identify and engage right expert or sets of experts. Also, they need to be engaged at right time otherwise engaging them to do a post-mortem of the failure of the project is of no use. The key to the success of expert judgment is to identify the right expert. There is no dearth of self-proclaimed experts in every field. Just don't depend on how good a speech they give, look for what they have delivered in the past. The challenge is to find the authentic one for your set of problems.

Some of the techniques that can help in identifying the right expert are:

Project Integration Management

As we know that to manage a project we need to do many different things, many times simultaneously. For example you have to communicate to all stakeholders and need to manage the scope at the same time. Have an eye on cost and time and see if some procurements need to be done. Human resource management keeps on happening and at the same time no untoward risk should be left unmanaged. To do all these things at the same time, we need a glue which holds everything together and that's where Project Integration management comes into picture. 

From PMP methodology perspective, Project Integration Management contains 6 process and have at least one process in each process group.

Project Management Fundamentals

The first question that comes up is: What is a Project? Project is considered a temporary endeavour whose aim is to deliver a product or service or result. The temporary nature of project does not means that the duration is short. It just means that there is a beginning and an end in the project. It has a start and an end. It's transient in nature. So on time scale, you would really see a project having a distinct start time and end time. Projects are also different from operations as operations are repetitive in nature. For example, going to office daily is an operation. However building a house is a project. Even building multiple houses is a project as each house even if they are same in design, still will involve a unique outcome. 

A project outcome may be a product like a new car. It could be a service like painting a house. It could be a result like reorganization in a company. 

From PMP perspective, three aspects are very important to the landscape of Project management.

1. Process groups 
2. Knowledge areas
3. Processes

Why applications succeed/fail

This is probably one of the fiercest debate in software development that why some application development succeed and why some application development fails. There are all sorts of philosophies around this. It's common to hear that if you use Framework X in place of Y the application development will succeed. Than there is a set of people who will talk endlessly about processes. How by adopting Process X in place of Process Y will help the organization. The moving variables in case of software development are immense.

Personally I feel the most important element of success and failure are the people. It's you and me. I

Why Projects Fail

This is somehow getting stuck in me for sometime now that the number one reason for a software project or for that matter any project failure is, when they fail to listen to the users. In context of software projects, when the projects are done by the developers for the developers there is a high chance that it's doomed to fail. It might have adopted best of the breed of technologies and frameworks but it failed to do the thing it was supposed to do for the end user. Put the greatest

What is DevOps

The new term doing round now a days is DevOps. Simply mean Development Operations. The notion of DevOps is all about alignment of Development and operations. and is quite relevant in many modern day web based applications where multiple deployments in a day are norms and not exceptions. The three important aspects that DevOps emphasizes on are:

• Communication
• Collaboration
• Integration

Nothing new in those terms. Pick any book or article on Project management and you will find traces

What kind of Software Development team you have got?

In IT world, if the most debated topic is anything, it's about why projects fail? There is for sure more failures than successes. Many successes which are there, at times are forced successes on end users. The end users are provided with no alternatives, and they are convinced or threatened to use the product, the way they are, the way they work.

Why projects fail? Very difficult to answer because there are so many things involved in it. Unfortunately, with software projects, it's difficult to visualise them and it makes the threshold to understand much higher. If we build a building, it's easy to visualise, as you can see bricks getting laid and the height gaining with time. It's easy to spot that it's going straight up and not becoming the

Bugs that should not be fixed

Of course,  we want to fix everything. It's extremely difficult to justify sometimes why we should not be fixing some bugs. There is always an angle to more security, better usability, better look and feel, a new feature which could be a killer. The points I am mentioning are more valid near the release and hold less water in the beginning of release so take your judgement.

• Usability is a never ending game. Understand your users. If they use application after going through training, then don't kill yourselves for usability. If you are making an application where

Agile vs Waterfall - The middle ground

In the good old world of IT development, we have the software development done as per the waterfall model. It was sort of a logical transition from the construction or mechanical world to the newly found software world. The big phases were defined as Requirements, Design, Coding, Testing and Production. It was more or less across the wall model in theory but was a big spaghetti of people and processes. Features went into production which were not part of Requirements and the intended requirements never made to the Production.

One of the major reason for the software developments to fail in waterfall model was the inability to