Oct 30 2009 10:00AM GMT
Posted by: Jaideep
Project Management,
project scope,
change management,
project manager,
software,
Project,
Software Project,
project implementation,
sign-off
One of the project managers of an ERP implementation company got himself into a tight corner. He found himself in a tough situation where an already ‘mutually sealed’ project scope asked for one or two new requirements (or changes in the existing functionality) from the client everyday while implementation. The broadly agreed upon requirements within the earmarked project modules came out with some changes here and there, some new add-ons. Customer is not ready to accept ‘no’ to any of the requirement since they have a mindset that they have ordered for a big project and are investing a large amount of money in it. The customer keeps on pushing for all their ‘now invented’ requirements to be mapped in the existing ‘project scope’. This seems to be a never ending story. The project manager is tightlipped to start a new module since the running one is not ‘done’ so far. And he also can’t say NO and mark any requirement as ‘out of scope’ since he does not want to annoy the customer and wants the project to be a success.
What should be done in this sort of scenario?
The project manager privately updated me about the situation and asked for my help to get him out of this situation. I told him if he carries out in the way he is – he will never be able to finish his project.
I advised him to have an emergency meeting with his client and share his pain with them. Make them clear that you are not saying No to their requirements but there is a need of a boundary line drawn with mutual understanding. Cater to so far documented requirements as phase I. Finish it off. Get it signed off. Whatever new requirement or changes come from the customer – document it, analyze it. Any requirement that is asking for more than 4 hours of efforts, put it in phase II of the project. As soon as you finish off the phase I, finish off Phase II, sign off. And so on.
Oct 9 2009 1:17PM GMT
Posted by: Jaideep
Software Project,
software delivery,
Project Management,
project manager,
Project Development,
project implementation,
project stage,
customer requirement,
quality,
product quality,
software quality
I have seen different type of drivers on road: some drive very fast violating all rules and regulations to reach the destination. Can this attitude work in software development and delivery? I don’t think so, if the project manager is more worried about reaching the implementation stage without bothering about the customer requirements, probably he is calling for a big bunch of troubles.
Another set of drivers are overcautious type. They will take lot of time in building customer requirements and will be uncompromising towards quality of product to such an extent that every deadline will be crossed without meeting it. Can such project managers be liked by customers? Or by the management?
Our next category of drivers is ‘stick to the route’ kind. They will never change the route whatsoever is the hurdle is and whatsoever is the impact on the delivery. Can customer accept a project manager who is damn fussy about the requirements?
Some drivers believe in ‘change with the wind’ style. They start for a destination, get a call on the way from the customer to divert to another destination, and the driver agrees happily. Probably this is the quality that customer wants in the project manager these days.
Jul 15 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Q-tag,
quality control,
Software Project,
Project Management,
stakeholder,
project methodology,
project management framework,
project implementation,
software build,
software implementation,
product approval,
Quality-tag,
project team,
development team,
implementation team,
testing team,
team,
QC,
QA,
business analyst,
re-testing,
testing,
Bug,
bugs report,
test report
In any software development and implementation company there is always a need of quality assurance and quality control people who own the responsibility of setting the right methodology and framework for development and implementation (QA), bugs identification and product approval (QC). Usually everyone in the organization has an inherent feeling that the quality is the responsibility of only these few persons belonging to this Q-department of the organization. Business analysts understand the customer and business requirement, hand it over to development team for building the product. Development team develops the product, and hands it over to QC team. QC team tests the product, finds out the bugs, and submits the report to development team. Development team fixes the bugs and returns the product to QC persons for re-testing and verification. After few exchanges between development and QC team, the product is declared as defect free and is released or launched for implementation.
If top management, development team, business analysts, implementation team and all other stakeholders think that quality is just the responsibility of only the persons belonging to quality department, they all are wrong. If Q-tag is limited to only a limited persons belonging to Quality department among all stakeholders, a product can never be built with great control on quality aspect.
Q-tag has to be on each of the stakeholder in a software project. When each and every person wears a Q-tag – the analysis, building, testing and implementation will be more justified. Otherwise there will always be a big question at the time of failure of a product build – that who is responsible?
Jul 8 2009 10:00AM GMT
Posted by: Jaideep
Project Management,
project manager,
project team,
project monitoring,
Project Plan,
Project Planning,
Project Development,
project implementation,
Software Project,
software development planning,
software product
At the birth (inception) of a new software project the project manager is puzzled and confused just trying to gather and understand customer requirements. He starts like a wanderer in the dark islands of customer for collecting various requirements and understanding their business norms. The moment he is able to collect this information, he aggregates to get the stock of ‘total requirements’. Understanding this makes him getting into ‘catching the rhythm’. Now comes his planning phase where he has large ‘in depth’ discussion with his development teams. By identifying different milestones for various project stages, he prepares a project plan. At this stage he is supposed to discuss this plan with customer and get ‘in sync’ with him. Once approved from customer, he breaks this plan into different stages plans to hand over respective plans to their ‘stage owners’. Development plan goes to development manager. Quality plan goes to QC head. Implementation plan goes to implementation head (himself mostly). Accordingly each stage milestones are identified which might be more than overall project milestones shared with the customer.
Then starts the actual war phase – the development phase. Meetings, discussions, brainstorming, logs, monitoring are all the weapons of this war phase. A product gets birth during this phase which gets vetted by quality control team. Documentations are also integral part of this phase.
Various test phases occur during and post development or build phase. Smoke testing, Unit testing, module testing, performance testing, security testing, load testing, functional testing… to name a few.
Now the baby has started walking. So baby is dressed well to take it to the grand function taking place at customer site. The function is ‘Implementation’. This is a long function, comprising of baby show, meetings, discussions, demonstrations, recordings, UAT, training etc. Once the baby is able to walk neatly in front of all the guests at the function, all praises fall on baby. The ceremony closing takes place. Project manager adds one more bullet of ‘confidence’ in his gun.
And starts over again for a new project.
Jun 29 2009 10:00AM GMT
Posted by: Jaideep
Software Project,
Project Management,
outsourcing,
requirement analysis,
requirement gathering,
requirement freezing,
software design,
software development,
software testing,
documentation,
project implementation,
training,
handholding,
post implementation,
Project Planning,
project control,
project execution,
project component,
project phase,
project offload,
project outsource
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.
Jun 17 2009 10:00AM GMT
Posted by: Jaideep
User Manual,
Software Project,
software project management,
key user,
stakeholder,
project implementation,
post implementation,
user feedback,
usability,
reliability,
stability,
durability,
report,
analytic,
feel and look,
product support,
project support,
live run,
product training,
software training,
training team,
implementation team,
project team,
project sign-off,
sign-off,
business scenario
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.
Jun 8 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Software Project,
software development,
Project Management,
project organization,
project team,
project delay,
project completion,
on-site development,
testing,
tester,
QC,
quality control,
project implementation,
software implementation,
functional lead,
technical lead,
quality,
software quality,
project quality
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.
May 27 2009 10:00AM GMT
Posted by: Jaideep
post implementation review,
Project Management,
project implementation,
Software Project,
implementation team,
end user,
project training,
project knowledge,
project lerning,
software features,
software functionality,
software performance
A successful implementation does not ensure the completion of project. The reality starts when the implementation team has gone back and users have started using the project in full swing with the help of training material, learning, knowledge and product. The health of users in respect of using the product is sustained, deteriorated, or improved will depend on many factors. A post implementation review is always important to understand the users understanding, pains and delights during this tenure. This will translate further into management’s pains and delights. The overall delight weightage has to be higher than the pain. In a blow of project implementation phase users might feel quite confident regarding the product features, functionality and ease. When the whole thing falls upon them, it usually drive them in confusion, wrong actions or stoppages. Or a smooth drive.
A post implementation survey will help in a real measurement on two fronts. One front will be users’ understanding, ease and comfort (or vice versa). Second front will be product’s stability, performance and functionality. It also will assess the after effects of a successful project implementation.
The conclusions could be misleading although and will require a deep analysis. A user’s lack of understanding may spell into products inefficiency or the opposite of it.
May 25 2009 10:00AM GMT
Posted by: Jaideep
Project Management,
post implementation review,
project implementation,
project sign-off,
implementation team
A Post implementation review is conducted after a substantial period from implementation sign-off. This review is to ascertain customer management’s and users’ experience on product in absence of product implementation team. The product has been implemented successfully and the team is gone. Ofcourse sufficient learning, knowledge, exposure and material have been imparted to users by the implementation team.
Post implementation review by the customer management with key users will spell out – user’s depth in using the product and product’s reliability and stability. The format of post implementation review document should be designed by the vendor management for the purpose of understanding the status of project after a certain period of usage post successful implementation. Filled by customer management in agreement with key users’ experience, the report is sent to vendor for their assessment.
