Oct 16 2009 10:00AM GMT
Posted by: Jaideep
project manager,
Project Management,
Software Project,
project team,
software,
Project
Involve all stakeholders throughout: This does not mean that all people involved in the project have to keep them available full-time during the project but it means that the knowledge about the project, project progress, shortcomings, bottlenecks etc. should be continuously shared across the board universally. All members should have the same set of information available with them at any moment of time. Involvement will definitely vary from person to person and phase to phase.
Collaborative, Participative, and Interactive: The information flow should not be one way. It should comprise of praises, shouts, appreciations, arguments etc. Let each brain contribute in making it a success.
Be Demonstrative: Lead the project. Demonstrate by actions what you want from other members. Use fewer words and more actions, especially in case of crisis or a problem.
Identify the lazy goat: If there is any lazy goat that is bound to spoil the show, indentify it at an earlier stage so as to avoid higher risk at a later stage.
Keep a set of your customer shoes with you: Borrow a set of your customer shoes, and keep it with you during the project. Put off your shoes frequently, wear your customer shoes and then have a look at the project pace, progress and status. It will definitely give you a different perspective view.
Oct 9 2009 6:29AM GMT
Posted by: Jaideep
Project Lifecycle,
Software Project,
project team,
project phase,
tester,
developer,
software development,
software testing,
implementation,
software product
Phase I: There is nothing called ‘off the shelf” product. It is all ‘made-to-fit’ technique. You specify your requirements and that too at a broader level. For micro level leave a red-mark at areas that need to be looked into at the time of building of software. The more red-marks will mean less precise plan and deadlines. The sooner we are able to convert these red-marks (not clearly known ones) to the clearly defied requirements, the better plan we can submit.
Phase II: The requirements will go to a team of developers who will build the outline or prototype of what is required by the customer, will get is approved from them and then will build the business requirements in it. Once they are through with it, the product will go to phase III.
Phase III: The product is handed over to a team of testers. These testers are technically stronger than the team that built the product. So this team will take the total ownership of the product from the team responsible for phase II. This team will find out the bugs, remove the bugs, fine tune the bugs and will hand over the final product to the implementation team.
Phase IV: The implementation team will interact with phase III team for any shortfalls in the product. Any new requirements will go to phase II team. Post implementation support also will be with the same team.
Sep 25 2009 10:00AM GMT
Posted by: Jaideep
Project Management,
project progress,
Software Project,
project initiation,
project closure,
project feedback,
project execution,
Project Planning,
project team,
project milestone,
project phase,
Development,
testing,
UAT,
QC,
quality control,
test report,
sign-off,
implementation,
live run,
project task
A project starts with initiation phase and ends up with project closure report. Then afterwards there is post project feedback (after a considerable amount of time given to the customer to get conversant with the product) and warranty support followed by support contracts over a period of time. Let us begin our story with the project initiation and proposal approval from customer. The real ball-game starts from here.
Now planning starts, teams are formed, milestones are set and teams move into execution phase.
Execution phase comprises of development, customization, configuration, testing, training, reporting, sign-offs, monitoring upto implementation, parallel run, live run etc.
And then comes the project completion phase with Project sign off.
During all the phases of project initiation, planning, execution… are the milestones broken into tasks and tasks further into sub-tasks unto the smallest measurable, achievable ‘hour’ unit. Or it is measured in days, weeks or months where it loses its continuity and rhythm. If everyday something is declared done, finished, achieved that is visible to the project team, stakeholders including customer, it carries out a satisfaction, rhythm, confidence and regular progress.
Sep 7 2009 11:00AM GMT
Posted by: Jaideep
Software Project,
project manager,
Project Management,
business knowledge,
project team,
team member,
software product,
product meeting,
project meeting,
customer meeting,
technical depth,
technical knowledge,
project feedback,
team feedback,
customer feedback,
project failure
Project Failure: First failure will downgrade the level of next project to be given to the project manager. Not only this, but it will also trigger hidden cameras in the organization that start monitoring each and every step of project manager. These hidden cameras could be top management or some selected down the line people working with project manager.
Customer Feedback: Organizations are taking customer feedback very seriously. A remark by a customer regarding a project manager – “I want this project manager to manager all my future projects ordered to you. Infact if you don’t depute this person as project manager, you don’t accept our orders” triggered such a magic that it immediately presented the project manager with an out-of-turn hefty increment. On the other hand a customer CEO sent a confidential email message to the CEO of projects organization stating – “We don’t want the current project manager to be seen in out campus with immediate effect” put a very big question mark on project manager’s capabilities.
Project Team Feedback: Sometimes even if Project fails project manager is able to survive if project team and customer give a positive feedback. Then the reasons are different which are beyond the control of project manager. But if project fails and feedback is also not very positive, all axes will fall on project manager’s neck.
Lack of Technical Depth: A shallow or artificial demonstration of technical depth will not help for long. Although project manager has not to do technical activities on his own but his depth of knowledge will definitely help in driving the project in right direction and meeting targets.
Lack of business knowledge: Sometimes smart team members manage many a weaknesses of their project manager if he has demonstrated his strength in certain areas. But the lack of business knowledge is something that will certainly affect the product built, customer confidence in product and project manager’s knowledge. And if project manager is not clear about the business concepts of the customer, his presence in project, product and customer meetings will not be as effective as it is supposed to be.
Jul 17 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Software Project,
Project Management,
people management,
HR,
QA,
QC,
Q-tag,
developer,
quality,
quality control,
quality culture,
quality building,
product,
stakeholder,
business analyst,
project manager,
project team,
development team,
testing team,
implementation team,
product build
People are not wrong, processes are. People in an organization do what they are told to do. Organizations who hit on people at the time of failure are not doing the right thing. It is the process that is to be blamed not the person with Q-tag. As long as quality is considered to be the child of people with Q-tag in the organization, and the culture is so around, the non Q-tag people will keep themselves enjoying building a product without quality. Why not blame the developers for developing so many bugs along with the requirements building. Why not blame the analysts who could not understand or translate the requirements correctly. Why not blame the management for not putting the right people and process at right place. This blame game itself is merely a scapegoat in any organization until the focus shifts from people to process enhancement.
Analyze the failure as a team involving all the stakeholders. Management, business analysts, project managers, project team, development team, testing team, implementation team have to sit together and brainstorm. Failure is to learn and not fail again. Mainly failure can occur due to following three factors:
Teams do not work and deliver in desired fashion – required innovation, awareness, training, cohesiveness, team building, and collaboration
Wrong people in the team – HR and management has to play a major role and look into the recruitment process.
Failed to build right product – needs training, demonstration, pairing, indentifying right people for right job.
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 22 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
User Manual,
Project Management,
Software Project,
project manager,
stakeholder,
project team,
project quality,
quality,
project walkthrough,
build phase,
project phase,
quality control
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
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.
