Fifteen Checkpoints for project managers - if your commitment towards project merely a Pretence?

You, as a project manager are most crucial factor of a project being the key driver. Your commitment matters most as it can do any wonders. Your real commitment can put fire in your team member’s belly to run the project full swing. But if your commitment is merely Pretence, it can wipe off the energy and zeal of others in the team. It can trigger on the pace by acting as a catalyst or adversely trigger off the pace by decelerating it.

There have to be certain checkpoints in your thought process that may ascertain if your commitment is in right direction or not. Let us see what those points as mentioned below are (against each I am mentioning if the commitment is PRETENCE or REAL).

If you

1. Believe – “All stages of a project are crucial and important as far as the overall success of a project is concerned.” – Your commitment is REAL.
2. Believe – “Each milestone matters and need to be converted to win-win for all for a smooth sailing towards this bigger goal.” - REAL
3. Believe – “All stakeholders have a stake and a part to play in the project. Overall every task and success has to cross ‘mine-yours’ barrier to reach at ‘our task’ and ‘our success’ stage.” - REAL
4. Are – “Intentionally creating conflicts.” - PRETENCE
5. Are – “Avoiding ‘important to be resolved’ conflicts.” - PRETENCE
6. Are – “Unnecessarily trying to prove your point (imposing your point) (putting yourself over the project). - PRETENCE
7. Have – “Lack of knowledge and understanding.” - PRETENCE
8. Are – “Giving more importance to emotions and feelings over logics.” - PRETENCE
9. Have – “High level of actions but poor planning.” - PRETENCE
10. High level of planning but with poor actions. - PRETENCE
11. Framework is not important – people, tools and management are. - PRETENCE
12. High performing teams are different from highly organized teams. - PRETENCE
13. Best practices do not require improvements. - PRETENCE
14. 100% test coverage means correctness. - PRETENCE
15. Automated testing is a silver bullet - PRETENCE

Projects do happen with the beliefs and actions mentioned above. Whether they end up in good or bad state, I am not sure. PMs do exist with these beliefs and actions. But they have to change themselves over a period of time, I am sure.

Outsource in a software project without losing control over it

We learnt in earlier two posts about the strategic decision of a management to outsource a complete project or part(s) of a project depending on certain factors, and the factors respectively. In this post let us see at the various components of a project that are most widely outsourced or otherwise we can say these are the components of a project which can be outsourced. It is very less often that a project awarded to a company is totally outsourced.

We are talking about outsourcing an activity of a software project. The most important components of a software project can be listed as:
Requirement analysis, gathering and freezing
Design, development and testing
Documentation
Implementation, training and hand-holding
Post implementation support

These can further be broken into various sub-components under each component thereby creating a tree like structure to have a bird’s eye view of any project. Planning and execution for each phase or component comes next with control everywhere.

Outsourcing mainly is the resultant of constraints in an organization.

Five Reasons of outsourcing

Outsourcing is neither bad nor good. It is a strategic decision based on certain parameters taken by an organization to offload some projects or part of a project to a third party. Offloading certainly comes with many boons and many banes. Offloading should be managed very carefully as the project delivery ownership still remains with you even if you are offloading complete project. Insertion of seriousness in the outsourced vendor regarding the project, requirements and its timelines is very important. There are many parts of a project that can be outsourced and as said above, the decision is purely management’s to decide what part of project is to be outsourced and to be awarded to whom.

Definitely in offloading the vendor-customer chain becomes longer depending on number of components of a project outsourced and the number of vendors involved. Even for a single component of a project there can be more than one vendor. And for a number of components of a project there can be a single vendor.

Offloading or not will depend on many factors that can be listed below as:
1. High number of projects
2. Shortage of skilled manpower
3. Shortage of right skilled people
4. High engagement of required persons
5. Lack of resources (in case of testing tools or otherwise)

Role of Vendor and Customer in managing User Manuals

As already has been discussed, User Manuals play a crucial role in any software project and are the solid bonding between product, users, customer management and vendor project team. The stronger this bond is the more comfortable and happy each stakeholder will be. Each player has to play a crucial role during the game of building of User Manuals. Both Project Management teams have to work hand in hand for that.

The quality of User Manuals has also been discussed in my earlier blog (Six Pack User Manual – how to build).

Let us discuss below the role to be played by the respective project managers in this regard:

Vendor Project Manager has to ensure that the user manuals are built along with the product development and are vetted/ approved by their QC team via a walkthrough. If need be they should as for draft manuals in build phase. If there is a foreign language issue, the Project Manager should also ensure that the user manuals are required in their local country language.

Customer Project Manager has to check that user manuals are complete in all respects, and checked thoroughly before handing it over to the respective key users

Six Pack User Manual – how to build

Six major key points that should be kept in mind while preparing User Manuals can be as listed below:

1. Simple – Never expect your product users to be as knowledgeable about your product as you are. Remember when you first time tried working on this product, how ignorant or untrained you were. The expertise that you have on your product has come over a period of time on repeated usage (in terms of implementation and training) of this product. So keep your User Manuals as simple as possible. Don’t use technical jargons, or tough language clauses. And even if you have to use them, break them in fractions or explain them in detail.

2. Extensive – Prepare User Manuals as detailed as possible. Use less text and more visuals/ diagrams/ flow charts/ process charts/ drawings/ illustrations/ screenshots/ pointers, highlights, captions, bold/ caps and italics to make is more user friendly, more understanding and less cumbersome.

3. Crisp and Fluent – On the other hand the User Manuals that you are preparing for your product users have to be crisp, up-to-the-mark, relevant, in-tune with the product, devoid of useless stories.

4. Quality – Imagine an airplane handed over to a person who doesn’t know ABC of even kite flying keep aside an airplane. And with the help of a user manual if he is able to take off and landing, the whole credit goes the User Manual. Build your user manuals like this.

5. FAQ – This is an important section of your User Manuals simply explaining two things. First is what – if situation that means what will happen if you do a particular activity. And second is if – what that means if you want to perform a particular task, what you are supposed to do. Understand the difference between what – if and if- what and build your FAQ section accordingly.

6. Right Person – Don’t imagine. Not at least that a good actor will be a good story writer or script writer. These are different jobs. Let developer do the development and chose the right person for understanding the product correctly and design User Manual.

Why User Manuals are so important in Software Project Management

The product owners or stakeholders might be many in a software project, but the real frontrunners who drive, run and use the software product post implementation are the key users and other users. It is their feedback that matters most. They must be the most comfortable lot on usability, functionality, reliability, stability, durability, resultant outputs in terms of reports and analytics, feel and look of the product. They are the one who are going to matter most in the success or failure of a product during and post implementation. The best tool to give them comfort, satisfaction, confidence and support is the User Manuals that they refer to most of the time during post implementation live run.

Even if the product is excellent and trainings are most rigorous ones, in absence of the project implementation team, every now and then the key users will be seeking help from User Manuals. User Manuals are the supporting agents for them at all times. That is why User Manuals have to be perfect in all aspects.

Infact a user manual prepared for product users should be such treated as a replacement of implementation and training team right from the moment the project is signed off and users start using the product in real business scenario.

Do’s (+) and Don’ts (X) in Project Management

Ten symptoms to know if your project is infected with influenza A (H1N1)

10. When you start getting increased number of bugs as compared to earlier releases

9. When your developers stop thinking about quality in code

8. When bugs pass through QC unnoticed

7. When you stop acknowledging quality efforts and start giving more importance to speed and volume of writing a code

6. When quality and development teams are not in sync

5. When you start feeling QC is a waste of money, efforts and time

4. When quality aspect is given least time in overall project

3. When management starts overlooking then overseeing

2. When customer does not get grossly involved in performing UAT

1. When above mentioned in point numbers 2 to 10 starts spreading in other projects

Ten Reasons of getting into pitfall of leaving a scope of software development at customer site

In the previous post we learnt what all could a software project could lead to in presence of higher scope of software development at customer site during implementation phase. Let us see what all factors are responsible of insufficient requirement gathering during business study phase of a project.

1. Incompetent team (vendor): Any project calls for a project team. A good team at both ends is important. Both teams have a substantial role during a project. If key users selected at customer site for delivering process knowledge to requirement analysts (vendor), there are higher chances of wrong information driven. The key users chosen should rightly be the actual process owners not essentially be at the higher level in the organization.

2. Incompetent team (customer): A right selection of project manager and analysts is equally crucial. The team has a short duration stipulated for gathering requirement information and understanding business processes. And mind it, this is not an individual race, it is a relay race, and weakest link will decide the overall result of the project.

3. Non commitment (customer): Well the process owners are the key users, but if are not serious or have not received the right message from their management may not be seriously committed to the vendor team. A non committed team will not be able to impart right knowledge, processes, practices and information required critically for a project.

4. Non commitment (vendor): A team of good committed project manager and analysts is equally crucial for gathering information. The previous experience on business domain and success factor definitely counts in.

5. Lack of time (customer): Key users identified if are engaged in other important projects running in the organization will be always short of time for providing right information to vendor project team.

6. Inappropriate discussions: In a limited timeframe of business study, there will be limited discussions. So all discussions should be crisp, purposeful, well driven and result oriented.

7. Improper documentation: Well explained requirements if not documented properly may lead to a wrong, incomplete product. Right people with right business and process knowledge have to acquire a good documentation skill also to lead the project to right direction and grand success.

8. Top Management involvement (customer): If customer management thinks that providing key users completes their job in the project, they are wrong. Their involvement in all important meetings is as important as the business is.

9. Project Organization: A right architecture of project team is very important. The project sponsor, project directors, project managers, key users, developers, implementers, technical leads from customer and vendor respectively should be the right mix of people.

10. Change in requirements: Any change in business or process during or after the requirement study phase has to be communicated to vendor team well in time, so that by following the change management procedure, the changes are taken care of properly.

Five pitfalls if you are leaving a scope of software development at customer site

Ideally, in a software project, for an offshore customer, the requirement gathering phase should be given an extra care to understand to a maximum extent so that the product developed and tested when ready for implementation at customer site requires no development. Practically, it is very difficult to achieve. The more it is left open to be handled at customer site, the higher is the chance of customer and vendor getting affected.

So that means the higher scope of development at customer site will change the team requirement and affect the overall project. Let us see what major factors will get affected and where could those lead the project to:

5. Money Factor: The most important factor is money. Any scope of development at customer site will need extra developers in the team besides the implementation functional leads. This will lead to an extra burden in terms of cost of technical staff not only in terms of developers but also testers.

4. Time Factor: Delay in project is inevitable in these circumstances when
requirements will be clearer at customer site at the time of implementation and
thus will change the overall implementation plan to accommodate development
and testing in between.

3. Quality Factor: Poor quality will be a major concern. Everyone knows you can not
take a bundle of testers at implementation site. That means limited testers will be
in under a tremendous pressure to release the product at the earliest and hence
may not justify with their job. This may lead to lot of holes in the pot –
intentionally left or unintentionally skipped.

2. Exuberance Factor: Enthusiasm, tempo, momentum, pace will all start
diminishing and in turn start creating frustration and dissatisfaction at both teams
level.

1. Product Factor: Product Failure, if not, then delays and unpolished product is
always visible on the platter under these circumstances.

All these factors, being inter-related will have recursive effect on each other thereby increasing each by manifold and everything may turn into a complete mess in place of a successful project.