If Project Manager is the engine of a fast moving train, have you ever imagined the amount of pressure he has over his head to ensure the safety of each passenger in the train, timely arrival at and departure from each station, creating comfort zone for each passenger so that each one has its own amount of enjoyment and learning during the journey, proper guidance for each station and journey to each passenger so that none misses their target lines of getting down at their destination station or boarding in from their respective station. It requires a great team effort from all ends and though the main load is on the engine, but each coach has its own role to play, each staff member and passenger has its own course of action at appropriate points of time.
How this all is managed is quite interesting to understand. Though trains do miss timelines at times but there are numerous factors for such delays – sometimes controllable, sometimes going beyond control. Depending on other trains, station’s capacity, staff on duty, weather, any normal or abnormal risk factors etc., all this is managed at its best to provide its passengers best of the experience and service. This is not a simple task.
Imagine each train as a project, each trip as an itinerary, each staff as team member and each passenger as customer, the complete model fits into a size of a huge project. And the basic things in place have to be in place for all this to happen smoothly.
Agile manifesto talks about ‘people first’ and not about software for a software development project. it emphasizes on valuing people above everything else. If you are able to achieve that, nothing is impossible to achieve further. Though the manifesto looks simpler to adopt but is quite difficult to adhere to. Ten golden rules that emerge out of Agile manifesto can be listed as below:
1. If you treat your people as resources, you are wrong. Stop it.
2. If you are aware about your goals, don’t let yourself defocused from it, at any cost. Stay focused.
3. Enjoy the pain of delivery.
4. Make your progress measurables as short as possible so that it remains small, less risky, more chances to achieve it and build a system to learn from each such step and document it. Make your feedback process a valuable content provider for these documents.
5. If you want your teams to be highly performing all the time, keep investing in them.
6. If you hire standard people, build a standard physical environment; but then don’t look beyond standard returns. If not, do reverse to achieve higher goals and higher returns.
7. Have more leaders and less managers.
8. To build a collaborative environment, you need to build a social environment first to bind them all together.
9. Best practices can continuously be evolved.
10. Develop leaders into collaborative leaders so as to achieve better results.
If you are doing MS or Doctorate (PhD) in Computer Science or Computer Engineering or Electrical Engineering you can apply for selection in software engineer job in various global companies. This would be a full time job initially being taken as intern. It would not be a regular in nature. One needs to apply after doing some research through various global companies’ website and by the prescribed date mentioned there, if interested.
If an applicant complying above requirements, possesses 2 or more years of experience in development on .Net and have exposure in development of n-tier application in C#.Net/ ADO.Net using SQL Server; it becomes a better probability. Additional exposure on software components like GoDiagram, MS Office InterOp, Intel DAO, Infragistics, OWC would be preferred by most of the companies. The application is assumed to have complete knowledge of OOT, Java, XML and computer graphics.
Generally for such startup jobs the scope of various positions include – problem definition, path finding for the solution, development of solution and finally its implementation. One would be required to play multiple roles rather than sticking to the same profile. This would not only enhance one’s capabilities but also provide him a broader picture of the product lifecycle in such bigger organizations. The candidate once selected, will have to start as a business analyst to understand the core business requirements emerging out of addressal of their problems. Basis this, one will have to propose alternative solutions to a problem.
A prototyping would be required for demonstration of various possible solutions thereby arriving at the optimum one. Then the selected intern would be required to engage with design and development teams to get involved in database design, relationships, n-tier architecture, front end, user interface, usability, GUI etc.
Lot of software are launched on regular basis. Mostly these days you will find web based, cloud apps more in the making. At times some software get launched without much hype and propaganda and otherwise many software are launched with lot of advertising, hype creation and propaganda. Why many software falling in both above categories fail in first go, largely to such an extent that they vanish totally from the scenario. Others do vanish for a while, get repaired, replenished, revamped so as to provide a better solution and then emerge in the scenario back to cater to their respective audience.
Why these software fail just after launch indicate towards many factors, some of which can be listed as below:
1. Product not meeting customer expectations: If a product does not deliver what perception it creates in customer’s mind, it is bound to fail.
2. Product introduction is not comprehensively delivered along with the product launch: If a product launch is not accompanied with a complete set of specifications on what is it bound to deliver, what are the basic requirements to run it, what inputs it requires and what outputs it is capable to deliver along with what platform and what all integrations are possible.
3. Market study not done appropriately: A software produced in isolation without proper study of market would not be able to get appropriate amount of target audience.
4. Uncleared bugs: If product has not been tested well in terms of exploratory, exhaustive testing thereby leaving lot of leakages.
5. Compliance: If the product requires some regulatory compliance and it has not been built, the product is bound to fall flat.
Each software product launched in the market has a specific purpose, targeted audience and defined geographies. A game for instance will be targeted for a particular age group, a specific genre and available for audience all across the globe. An application related to small business segment might not have such a versatile scope as above mentioned for a game app. The latter app might have limited audience, limited part of financial transactions, limited countries and limited segment of business groups. One needs to be clear about all these factors while planning to procure a software product emerging out as a need based on the requirements specified by his business, family, personal or other fronts.
A 100% good app might appear to be bad if it is not parametrized well prior to making a purchase of it. All requirements of a user might not get catered to by any software. The set of requirements need to be matched well with the offers made by a software product. A better way is to first build a pool of software that would be capable to cater to your specific needs. There could be a level of compromise if you are going for a ready made product with negligible scope of customization. The rate of compromise would definitely vary from product to product among all the products lying in your shortlisted pool.
Next would be the exercise to sort of products where compromising is less. Among these sorted products chalk out those which do not match with your pocket. Once that is done, the pool by now would have shrunk to maximum five products. Now is the time to compare them one to one on the basis of business needs, price, vendor, availability, support and product life.
Testers have a dual responsibility while testing a product handed over to them. On one hand they are part of the organization that is responsible to launch this product. Development team, after finishing their coding part, hands over the product to testing team who in turn have to ensure that product is ready for UAT and finally to launch in production. From business and development angle, testers have to ensure that product marries well with the organizational values and standards, meets business goals, aligns well with customer requirements, developed with appropriate standards of coding and database management.
On the other hand a tester is also required to put his feet in end user’s shoes and look at the product from that angle, the way end user would look at it. Keeping aside the technicalities, standards, procedures and policies; the end user would be more focussed about the functionality, usability, navigation, ease and comfort, business flow and rules etc. From this angle, the tester is required to test the product in a manner so as to ensure complete satisfaction of end user.
That way, if you see, tester has a tough task as hand, provided he understand the gravity of matter. He is supposed to align business requirements, technology, business flow, and end user together on one platform by means of testing a product.
Nobody would like to have a bug prone app as far as end user is concerned. When an end user is paying for an app in the market, it means he expects to get what is committed to be delivered in a most satisfying manner with highest level of accuracy. Especially when the app is related to core business or financial transactions, this expectation level goes higher. Each of the end user who is going to use an app might not be a party to the core users who perform UAT (user acceptance testing).
One the other hand there is someone in the team who would be happy to encounter as many bugs in the product handed over to them as possible. This someone is the bunch of testers who are supposed to go all kind of testing in the product handed over to them by development team. This is the stage where the product is expected to become completely neat, bug free and highly stable. The higher the number of bugs encountered by testing team here, the better it is for the development team. The next stage which is UAT must have very minimal amount of bugs in the product and mostly those should be user or business specific. UAT bugs could be related to usability, navigation, functionality or business logic.
That is why it is interesting to know that if the core user from customer front is testing the relevant module of the product along with testing team, concerns related to both examining parties get addressed in one go.
Web based application from TeamSnap Inc. that allows fans, sports teams, sports groups, sports enthusiasts, sports clubs and sports communities to communicate among themselves, stay connected and organized; has already been a big hit among its more than half million end users spread across 94 countries across the globe. TeamSnap, having their HQ in Boulder and have their development set up in Portland. In 2010 TeamSnap took a big challenge of developing this web based app for iPhone users. This went off successfully and finally the launch for iPhone, iPods and iPads was widely accepted by users. Average rating of this product was over 4.5 out of 5.
During the launch, Dave DuPont, CEO of TeamSnap, discussed about their decision of going for this development was inspired by their large amount of customers being iPhone users. So what was being missed in web based app got overcome in iPhone based app. Users who were on the move or away from their computer had not been able to access web based app and hence used to miss lots of last minute adventure that used to happen before, during and just after the match. With the launch of this iPhone app, users got overwhelmed when they were able to overcome above obstacles.
The app cam with many features like Match roster, team composition, schedules, timings, locations for all games and even of the practices. The users had an option of demanding map to reach to their destination. During the match, they could upload and view photographs, in real time. Any broadcasted messages or announcements from team manager, or team members was available to users for their teams marked as favorite.
This is a lovely video explaining Dr. Robert Claldini’s research on Persuasion and thereby deriving Principles of Persuasion which have been widely and globally accepted. Dr. Robert Claldini is Professor Emeritus of Psychology and Marketing in Arizona State University, U.S.
According to the Principles of Persuasion identified by Dr.Robert Claldini there are 6 main factors in any situation and under any kind of circumstances that make us say YES. These 6 factors impacting human tendencies and behavior are:
Overall it is a lovely video and you would definitely enjoy. Just correlate it with the behavior of your team members, team leaders, team managers and project manager.
A project and its project manager are supposed to be most closely knit entities. Bonding between the two has to be strongest as compared to any other bonding existing among various teams or stakeholders engaged in a project. There are certain weakening factors that would force project manager to drift away from various projects he or she is managing and that could lead to a big disaster. most affected entity would be project manager, if such disconnects exist because it is project manager who can ensure their non existence.
Five major disconnects in that regard are:
Joint Pain: Organizational requirements, customer requirements, stakeholders concerns, teams’ issues have all to be in the agenda of project manager. Any pain areas related to these entities can’t differ from project manager’s pains. A one to one alignment is very important, else the two boats will be sailing in different directions with two different kind of missions which shall lead to a big disaster.
Reporting: Incomplete reporting, wrong reporting, or delayed reporting; are all deadly weapons, that are absolutely enough to kill any project and ultimately the project manager’s growth and career.
Timelines: Timely delivery of report is critical to drive any project. A ship is sinking, and if control tower is not reported about it with complete details will lead to vanishing of ship under deep waters with no traces left.
Self Tracker: It is important for a project manager to maintain a tracker for his own tasks to overcome all above mentioned hiccups.
Escalation: Escalation to next level is very important for anything going out of control so as to align all stakeholders and plan collectively for this risk mitigation in a best possible way.
Project Managers could be of various types. No two project managers can be alike in terms of managing their project, people and events. There could be some similarities in some aspects between two project managers but their way of tackling a particular situation, handling management, managing teams, tracking milestones, process of documentation etc., cannot be same. Let us see what kind of similarities lie in animals of jungle and project managers:
1. The Lion Project Manager: A project manager resembling lion kind behavior will have excellent leadership skills. He would not hesitate in exploring the unexplored arenas. He would be very cautious about his pride but will not miss out any opportunity. He will always stay connected to his teams howsoever distant he is from them at any moment of time. He will have current status of his project intact better than anyone else among stakeholders.
2. The Wolf Project Manager: A project manager whose working style resembles with a wolf would always be clear on what he needs to make his project successful and how to get what he needs. He would be perfect in sniffing out any good ideas pulping within project teams and tracking those ideas to give them a real shape.
3. The Spider Project Manager: Spider like project manager would always be sensitive in spinning his web and would design it based on the project requirements. the depth, width and design would always optimum enough to keep all his contacts, tasks and teams engaged and up to the mark.
4. The Flamingo Project Manager: This category of project manager would never be seen at a single place with single team talking about single task, for long. He would always be on his toes, hunting for better opportunities and ways to complete his project.
5. The Cheetah Project Manager: Project manager falling under this category would have a strong networking irrelevant of distances or vicinity. He would always be fast, dependable, and full of energy; all the time.
6. The Parrot Project Manager: A parrot like project manager would be a natural talker and full of good amount of advice for anyone having any kind of problem. He will have a good personal rapport and informal bonding not only with his team mates but others too. He is perfect in selecting right kind of words to say under any kind of circumstances and the right kind of opportunity to speak them out.
7. The Chimp Project Manager: He would always have lot to say. He is a firm believer of teamwork and would love to explain minutest of the requirement to each of the member of his team, in complete detail.
Five Lessons For Project Manager From Robert Kaplan Latest Book What To Ask The Person In The Mirror
Recently read a good book from Robert S. Kaplan titled as What To Ask The Person In The Mirror. Robert Kaplan is well known as co-creator of the Balanced Scorecard. Formerly he was vice chairman of Goldman Sachs. In this book he has raised some genuine concerns related to Leadership like – Why focus is important for leaders? Is it possible to create leaders or it is only born leaders? How leaders cope up with setback? What all changes happen with moving one step up on the ladder of growth and success?
A deep introspection is required for a leader, as per Kaplan in a way that when a leader stands in front of a mirror, he must ask some basic fundamental questions from himself. Robert S Kaplan teaches in Harvard University in the field of management practice. Kaplan states that leaders have a very good quality of posing confident all the time even if they are not sure about the situation at times. What lessons can a Project Manager (Knowing that a project manager has to be a great leader) get from Robert S Kaplan based on his latest book What To Ask The Person In The Mirror, let us take a note of them as below:
1. There is a great relationship between Project Management and Being Focused.
2. Leadership qualities can be inculcated in a project manager by means of adopting few important
3. A good project manager has to be a good actor too, especially at the time of crisis.
4. A good project manager becomes expert over a period of time on getting out of state of confusion
quicker than others.
5. A good project manager when not sure about their decisions, takes a call based on their inner
There is a very interesting story that I read online recently. When an abandoned fort that was used as a prison was being stripped by a group of contracted laborers, they discovered a very amazing fact. When this team was dismantling this jail if was found that huge sized powerful locks and strong/ heavy doors were used along with solid iron bars covering the windows. Surprising fact that came out was that the walls were not the real walls. Those were constructed with only clay and paper but the finishing done on them with paints etc was so realistic that those appeared like iron walls. If one had wanted to escape away, walls would have easily broken with least of the efforts and all the prisoners would have escaped easily. Nobody ever tried because not a single person thought about it.
Does that not happen in a project. The teams working on various assignments of an ongoing project. We all become prisoners of our fears of exploring new possibilities because we have to follow predefined processes and procedures. At some moment of time someone needs to dare and try breaking the strong looking weak walls around so as to get some real fresh air that pumps up additional photons of energy.
Can this element be part of all projects. What exactly will be its driving elements and what will it derive out at the end can be quite interesting. Probably it is the first time across the globe that we are using this term for associating with project management. The term itself reflects that it is more connected to ‘people’ factor hence all teams and team members will be the substantial driving and deriving factor of this value. Now if we see, it is only the people who are most crucial and critical component of any project. Rest all entities required during a project – be it resources other than people, be it travel logistics, be it location or space; all become secondary in front of ‘people’ required for a project.
If it is people who are primarily responsible to run a project, what do we really do to understand/ assess something in objective terms known as “Happiness”. We use a number of metrics to monitor and control project to manage it. Some commonly used activities being used worldwide are – project review report, project review meeting, project activity completion report, sign offs, milestones identification at the beginning of a project and their closures as per timelines, customer requirements documentation and a large amount of other documentation, project closure & sign off and finally project support. Ways to perform these activities can be different but goals to achieve while monitoring and managing these reports are more or less common.
In previous three posts we discussed about what one team thinks about other teams while working on a project. There was a picture shown in the post where we discussed what Developers think about other teams in a project. Further on we saw what Design team perceives about other teams of the project. Finally we saw what QA thinks about various teams working on a project. In last of the perception series we will see what Project Managers think about various teams of his project viz QA, Development team and Design team.
A project manager has his own perception about his designer, development and QA teams which can be listed as below:
1. Project Manager thinks about Development team comprising of guys having multiple number of hands and capable of doing various different things at the same time. One who does not fit into this kind of bill can not be called as a developer. Developers are treated by them as multi-tasking guys.
2. Designing team as perceived by Project Manager is a team of highly skilled set of kids having mindset of an engineer.
3. Project Managers think themselves as the most handsome, dashing, not less than the most famous hero of the film industry. They think they are the most charismatic persons on this earth who can do any kind of wonders.
4. QA team is perceived as a set of referees keeping a close watch on the boxing match going on between Business requirements and development team’s understanding of the same.
Referring to last two posts where we discussed what is the general perception of Developers about various other teams of project, and what perceptions Designers carry about other teams in the same context. Based on the picture given in the earlier post perception of Developers about various other teams, Let us now conclude What QA thinks about other teams in the project:
1. QA takes Developers as a bunch of monkeys who are made to sit on laptops to do coding. So basically they treat Developers as copy cats and not related to the trade they are into. These guys while writing codes etc keep thinking that they are doing something very great but finally they don’t produce anything other than a piece of junk.
2. QA thinks Designers as a bunch of kids wearing different color wigs on their heads and enjoying life by their playful activities.
3. QA perceive about a Project Manager as a person who is always behind the schedule and late as per his planned activities. He is so engrossed in monitoring and managing project that he misses all tracks and timelines.
4. QA thinks that the guy in QA is a Superman who is capable of doing anything on this earth. They are born to help developers to come out of their graves and convert their lousy, useless stuff that they produced into some meaningful stuff with the help of QA guys.
Referring to the interesting chart/diagram in my previous post depicting what one team perceives or thinks about other teams in a project. In this post let us take that interesting analysis a step ahead. In previous post we discussed about what development team thinks about themselves, Designers, Project Managers and QA. In this post we will talk about what Designers think about themselves, Developers, Project Managers and QA team members. Looking at the same picture of my previous post, here is the analysis:
1. Designers think about Developers as a bunch of old people having heavy spectacles with no charm left in them. Designers think that developers find no charm in life and in this world. They do only one thing in life – coding.
2. Designers think about themselves as most sophisticated, modern, state of the art guys having no match in this world.
3. Designers think about Project Managers the most dangerous species on this earth having no knowledge and lot of destructive power. They have no knowledge about the technology and are always anti to what Developers do.
4. Designers think about QA as posers, actors who always pose that they are great thinkers but otherwise are not.
What an excellent crux has been concluded in this one picture by QATestLab on their blog. It depicts how a team during a project guesses about other teams working in the same project. Probably it might have been designed upon some large amount of experience and a feedback from various team members. If we leave two heavyweight stakeholders – the management and the customer – and keep them aside for a while, we are left with Developers, Designers, Project Managers and QA as other stakeholders of the project. Let us see what each one of them perceives about the others as below:
1. Developers think about themselves as the solution providers sitting at the top of the ladder and being capable of solving all kind of problems.
2. Developers think of Designers as kids playing with colors.
3. Developers think of Project Managers as totally free kind of species always relaxing and sleeping, even on their seat in the office.
4. Developers think about QA as ‘big brother’ with only one mission in life – watch them and beat them all the time.
What does project manager do in such situation when issues from all around have grown tall, intermingled and he find nobody around to discuss or consult about these issues. This is a practical scenario where any project manager may find himself into. It is quite important to know that under such circumstances the whole project is in shambles, teams working in silos – with no synchronization among them – within the team or among different teams. That situation is very serious.
Point to ponder here is how a project manager has managed (or mismanaged) to let his project reach to such a situation. This can not be treated as a normal situation. When things are totally haywire it is more important to understand what had made this project reach to such titanic condition and why has it happened. Once what, how and why are clear, next step would be to build a solid fence so that it does not happen again.
As per a new study concluded recently that pointed out that organizations across the globe are focusing more on tailor made business solutions rather than going for standard solutions available in the market. As a result of that, software application development team within the organization is getting more and more loaded with new requirements whether related to new applications or customization in existing applications. Without doubting on the capabilities of the software team, the fact is that the gap between business requirements and availability of applications to take care of that is increasing.
AS the gap keeps increasing between the demand and the supply, so is the frustration at both ends. On one hand management appoints high salaried software developers expecting that whatever requirements are given to them must be executed and completed by them within no time. On the other hand with increasing requirements and expectations from the management, development team starts declining in delivery and productivity and finally both management and development team reaching to same conclusion that it is becoming impossible for development team to deliver or understand business requirements.
Why it happens so?
Project Manager is not the only person to be blamed for failure of a project. Like the credit of success goes to the whole team, same must happen at the time of failure too. But that is not the case. Most of the brunt falls on the head of Project Manager, and there is a reason for that. First reason is that Project Manager is the whole sole in-charge and primary coordinator of his project. He must be aware of all the good and bad things happening in and around his project right since the inception of project. Timelines, project tasks, delays, problems, risks – all angles must be handled properly by the project manager.
At times he might have to escalate a serious issue, bottleneck or showstopper to the higher management without whose intervention it is becoming to control or resolve. At such times when things go out of control of project manager, he must understand the gravity of matter and immediately prepare a detailed report to be presented to higher management with a high alert. This is what is the most important action to be taken if project reaches to a juncture. If it is not the project manager who has to raise a red alert then who else will do it. It is essential for project manager to stay away from a condition of going into the shell and start thinking that such highly critical worsened situation will come back on track on its own.
If that could happen, then probably project manager’s role would be much easier. One can’t live on hope of happening of miracles to save the sinking ship.
G4S is a worldwide largest personal security company having almost 650,000 employees on its role. Recently they had a major setback in a project that was done with London Olympics where they had to supply a large number of guards. They failed to recruit such a large number of employees and therefore failed to place them for London Games as per the contract. Such a devastating failure gave them a bad name all across the globe. Some important points that come out of it may be listed as below:
1. G4S probably overestimated their capabilities and failed drastically.
2. G4S does not work in an organized manner and hence they had to fall flat on the floor while trying to dance in
the biggest ever title competition of their life.
3. It will take a decade or so to recover from this shocking failure as the whole organization has got shattered
with this failure.
4. Overall they have been exposed as an incapable MNC company that shouts more and delivers less.
5. Top management of G4S Headquarter in UK could not clearly spell out the actual reason of their failure except
pointing out fingers to one another in the team.
6. UK Army soldiers had to be recalled from leave to fill up this gap created by G4S for London Games.
Gradually besides getting a huge setback to their failure all across the globe, their latest financial results have put them in shambles. It is apparently clear that the shareholders have lost faith in this organization. The current results have shown a fall of 34% from their previous year results. London Games failure costed them almost USD 90m.
Let us learn that large or small – whatever is the project size, we should be committed to whatever has been promised to the customer, whatever may the situation be. Has Nick Buckles learnt any good lessons from this drastic failure?
A project manager has a lot of tasks in his bag at any moment of time during a running project. Distribution of tasks to right guys is an art but requires a science behind it. Before these important tasks become obliterate, it need to be allocated to some of the team member so as putting in one’s radar with a target timeline for its completion. It is not that any task can be allocated to any team member. Each team has its own specialization in specific tasks or roles. Assigning them appropriate tasks helps both sides in attaining a win-win situation. Team’s morale, on one hand, stays high, if they get most appropriate tasks and are able to close them with an optimum speed.
This keeps whole team’s performance up to the mark and overall project progress pace too stays under control. Even within a team, if a wrong hat is chosen for a wrong guy, it may put a bigger impact on the overall health of the project. Choosing a right task for right candidate though might not be possible for a project manager to manager up to the last level, but building that culture is always in his hands. If a proper message is conveyed to team leaders regarding assigning appropriate tasks to each of the team member will also help in building a higher level of understanding of their team members among team leaders.
Team leaders, once are able to understand the highs and lows of each of their team members, will always be able to identify right kind of guy for assigning them right kind of tasks.
There are two lovely messages for a project manager on making decisions and promises/ commitments during project lifecycle to various stakeholders on behalf of various teams.
On Decision: The message is – “Never make a decision when you are angry”
make it a golden rule in your life.
On Promise: The message is: Never make a promise when you are happy”
This is a very important message to follow.
All kind of issues arise during any kind of project. They can’t be avoided. Rather, being a project manager, you must welcome as many issues as possible from any corner of your project management teams. The more, the better – in terms of openness and surety of things moving in a right direction. In fact if you are not getting too many of queries, doubts or questions regarding the project, you can very well assume that things are not settled well below the still water. You can perceive lot of turbulence below, in that case, that may lead to troubles at a later stage.
Best way to manage issues is to have a response time, turnaround time and resolution time – commitments well defined in the system. And if this system is having a good alert and escalation on top of it, it would a cherry on the cake. Focusing more on the ageing of unresolved issues is more important at any stage of the project rather than on the count of issues. A pending issues list with a count of 5 but staying unresolved for 20 days is more dangerous for the system than having a count of 20 issues remaining unresolved for 5 days.
A project manager can’t afford to vanish out of the stage during any phase of a project. His visibility and availability even at the time when he thinks it is not required, will always help in achieving better results during the project management. It does not mean that you have to be present in front of all team members all the time. That might not be possible, especially during offshore project when your teams are scattered geographically. But there are ways of being present and making your presence felt across the teams and during all important project review meetings.
Avoiding team members for the fear of their queries of doubts will be a big disaster, if you think of doing that. The privilege that you seek from them at the time of asking them any kind of question or status related to project tasks, in a similar manner, provide them this privilege of coming to you, or approaching you, the moment any of the team member has an ambiguity or doubt related to any of the project tasks. A doubt infused in a team member’s mind, that remains unanswered, may lead to a sleeping volcano that may lead to a huge burst at a later stage. This may lead to things going out of shape or control, and at times, a complete failure.
Questioning and Criticism in a constructive manner always leads to the betterment of a project rather than hiding out faults or leaving some threads untied, thereby creating a disconnect among team members.
A project manager with short tamper, over reactive attitude and less communicative always calls for trouble for himself during his important task of project management. Being crisp, to the point and precise in his communication is as important as being over communicative. Over communicative quality does not mean that communication can’t be precise and crisp. Both these qualities can go hand in hand. And rather PMs with these two qualities get extra thrust in their career and tasks.
There are lots of things that might be clear in a project manager’s mind while communicating to his various project teams or the stakeholders. Imagining that all, to whom he is communicating, will be on same platform will be a big mistake. Hence to bring them all on the same page before putting down the points you want to put in front of them, it is important to build a proper background so that everyone in the room is clear about what you want to convey and what you want to achieve. Otherwise there will always remain a big gap between what exactly you are trying to convey, what they all are understanding out of that, and on top of that what all you intend to achieve with this communication.
The wider the gap, the more will be the chances of things going haywire. And once during any phase of the project, you lose track and deviate from your desired goals, by means of improper communication, it will be taking lot of efforts, energies and time to get back on track. This could lead to disasters and larger financial impacts.
Being precise is a very important quality of a project manager. Being precise does not mean being short in communication or being non elaborative. Being precise means crisp and to the point in all kind of communication during any project phase and with any of the teams engaged in the project. At times you need to be a little explanatory in terms of preparing some background for what exactly you want to convey to different stakeholders of a project or to the teams engaged in a project.
Where being precise in your communication is a big boon on one hand, on the other hand, it is not too well groomed feature found in project manager. Most of them do leave a scope of non clarity, ambiguity and wrong message delivery during their conversation in project meetings or communication to project stakeholders. It is very important to avoid such kind of mismanagement so as to avoid confusions that can become roadblocks in project progress.
Acquiring precision in getting to next level of precise communication is an uphill task as soon as you start reaching to higher levels. First of all it requires a change in age old practice of the habits of communication that have all these kinds of shortfalls. Change always invites resistance. Conviction is the first thing that needs to come for that change.
If you are not convinced that your communication lacks in certain areas that need to be polished and groomed, nothing on this earth can bring in that change that is very critical and important for you to acquire.
It is interesting to note that Indonesia won over US and Europe for testing of this great feature of mobile transfer by this Canadian mobile company while planning the launch of BB10 (BlackBerry 10 platform). There are certain factual reasons behind choosing Indonesia and not US or Europe for that matter for this serious testing of mobile transfer module in BlackBerry on BB10 operating system. One major reason is the volume of users of BlackBerry in Indonesia as compared to the similar kind of users in the whole of Europe or the U.S.
Testing of two main features – one mentioned above – the money transfer on BlackBerry mobile and another one is BB Messenger services, has started in Indonesia since December 2012. Another major factor of performing this testing here in Indonesia is that this Canadian mobile manufacturing company is anticipating better results in one of the major emerging and fast growing markets like in this part of Asia rather than in Europe or the U.S. BB10, the new operating system of BlackBerry was launched last month only.
The tie up has happened between the mobile giant BlackBerry and one of the top Indonesian Banks – Bank Permata. Notably, Standard Chartered Bank is one of the stakeholders in this local bank. The main focus is on testing of feature of money transferring among friends through the BBM10 messaging services.
Almost a million of the total population of around 250 million in Indonesia own credit cards and keeping this in mind, the country has been chosen for this testing.
Ten Organizational Factors That Make It Possible To Complete Projects Successfully:
1. Culture: Culture makes a lot hell of difference in the mindset of people working in an organization. Though Best in Class and Worst in Class are subjective terms and are in relevance to something or the other, it is the overall morale that makes a difference. Why keep thinking yourself belonging to the latter class and why not to former one. The organization giving a feel of ‘best in class’ is always in a win-win situation from all angles.
2. Ownership: Leaders are not born, they are made within the organization. Once an organization learns this mantra, it is able to transform its people from their current level to next level thereby attaining higher results and better closures.
3. Mentoring: This is done on papers in many organizations but doing it in actual, effectively and in a measurable manner is not everybody’s cup of tea. But if done ethically, it produces excellent results.
4. Empowerment: Empowering down the line is something that is a great thing. For empowerment, it is important to groom and enablement by means of teaming, training and coaching.
5. Respect: Respect is something that is weighed more than monetary benefits one gets in an organization. Best bet is to get it in the blood of everyone by means of building a top down approach and culture.
6. Rewards: Some organizations think reward is a bad technique. This could be true only if rewards are measured in terms of money. There are better ways of rewards and recognition.
7. Accountability: Empowerment, respect, mentoring and ownership are such things that automatically bring in accountability in clear terms.
8. Celebration of Success: Success is not everyone’s cup of tea. Let there be as many possibilities and occasions to celebrate success. The higher the better. It builds a health competition among various teams and within the teams.
9. Growth Roadmap: A clear cut growth chart visibility is dear to everyone but is not clear in most of the organizations.
10. Freedom: Give space to the team members along with responsibilities and accountability. Ownership and accountability seek some kind of freedom to execute and complete tasks in time.
Microsoft has decided to tie up with local software development professionals with dual motive. First, to act enabler for those guys in terms of providing them a platform and resources for their hunger for coding & development. Second, to get a benefit of engaging local brains for development of locally required applications. This initiative is being taken up by Microsoft in Nigeria where they are enhancing local developer’s skills for the purpose of their higher level of involvement in innovative software projects aiming to cater to all kind of local requirements from the market.
Recently a one day exhaustive workshop was organized by Microsoft for enhancement of skillsets of indigenous developers in order to increase their productivity manifold. Microsoft encouraged use of all kind of their innovative products in any manner thereby aiming to produce various kind of solutions. This one day workshop attracted large volume of local developers from various corners of Nigeria who understood that acquiring additional skills and innovative techniques would help them in acquiring better position in the development industry. Another aim of the workshop was to increase profitability of developers in whichever field they choose to work in.
It was bascially initiated by Microsoft Anglophone West Africa with all round efforts of their Developer Platform Evangelism Lead, Shina Oyetoso who explained that the motive behind this drive was the initiative of their mission Microsoft 4Afrika whereby they intend to empower local development community in various aspects.
How many companies would have adopted Agile and then felt helpless in carrying on with it? There would be. Plenty of them. Such organizations get influenced with any new technology, methodology, process or concept in such a manner that they forget to do their homework before deciding on jumping into it. There are certain things that need to be examined, introspected and mapped with current state. Top management needs to be interrogated on their reasons for going for any change management tool. Once the clarity is established, they must be then able to answer next set of questions – What do they plan to achieve by adoption of these change agents? What is the time frame they have in mind for getting results? What is the occupancy rate of various concerned people in the organization they anticipate for this transformation?
Sometimes reasons are not clear to the top management on why they are zeroing down on the adoption of say Agile. The whole exercise must be stopped immediately for any further actions as long is this clarity does not reflect from the minds of each and every top decision makers. What is the level of scaling up in the organization is being anticipated – must also be known for the change agent stakeholders. Is it going to be a pilot for just a single project or once pilot is through it will be deployed horizontally across all projects running in the organization.
Lean is another concept that can be looked into. Organizations are adopting Lean and Agile together for some specific projects. Tracking of projects under Agile is very much different from the Lean projects. At times, Agile and Lean might be though of as complementing agents to each other and giving an extra edge, thrust or power to projects in the organization.
There is not limit in making effort for making a project success (or failure). Using a latest technology or tool for managing a project does not guarantee you that you are going to succeed in your project. There are a lot more things that matter. Adopting agile, for that matter and actually following agile are two different things. Sometimes even adopted processes do not gel well in the environment depending on certain factors. Getting some processes in the system just for the sake of some higher official’s demand does not ensure that the system gets into the blood of teams.
Provision of scaling up of any process or methodology is very important in any system. Not having a provision of scaling up ensures least scope of improvement of enhancement in the system. This kind of approach sometimes leave a project, or for that sake, the whole organization as stagnant with no outflow of shortfalls in the system as there is no outlet for the same in this kind of system. Popularity of a system or process elsewhere does not ensure it will be successful in your environment too. A thorough study before adopting any system for its fitment in your kind of environment is important. If this is skipped it is 50-50 chances of its success since you have taken a risk of its success without getting deeper into its adoption and sustenance in your culture.
What kind of project fit in what kind of methodologies or processes needs to be intervened prior to adopting any kind of tool, methodology or process.
Around a couple of years back a very interesting article was published on Forbes website educating on importance and role of Lean and Agile in Software Development Organizations. Dan Woods, has presented his valuable ideas on how agile software development gets catalyzed by using Lean practices as used in manufacturing companies. Dan Woods in editor and CTO (Chief Technology Officer) of a research company that focuses on the changing needs of CIOs (Chief Information Officers) and CTOs.
Fast changing scenarios and highly dynamic signals from the markets impacting development and delivery logistics heavily thereby demanding a quick response if a firm grip is required on the business. Most of the successful companies which are able to play this tough game beautifully do it by adopting Lean manufacturing principles. These adoptions provide the organizations an extra pound of power to manage fast changing scenarios on the trigger of events. Instead of building large stocks and then struggling for orders, the better way is to get orders from customers and then manufacture only the required quantity with a target of ‘first time right’. That way they save both – space for stocking inventories, and money that gets blocked till the time you are able to clear off your stocks.
Transformation in Software development has though seen Agile development methodology but still there is a larger chunk following Waterfall development methods. The biggest drawback of Waterfall development methodology is its being too rigid in catering to change in customer requirements in between and making changes accordingly. Whereas Agile methodology is entirely opposite of it. It never believed in customer requirements blindfolded. A regular confirmation from customer is a continuous process by getting minutest of built vetted by the customer and then move on to next incremental step. This way a very high level of quality level is attained and maintained throughout the build as the defects get addressed during small portions’ internal testing and then UAT by customer.
California High Speed Rail Project amounting to USD 35 million covering 30 miles of track laying between Madera and Fresno has been awarded to PGH Wong Engineering and Harris & Associates, both of them based in California. The project has been awarded on the basis of their merits and excellent performance in various other projects they have taken previously. Both are having an ability to handle larger projects and managing them in a highly professional manner.
There will be a Project and Construction Management Team that will stay on the top of these two companies to keep a vigilance and overseeing the periodical success of the project and in case of any alarm to be raised.
If you are a Project Manager and are widely acceptable among all your team members for all your directions, plans and timelines that you assign or decide; you are either a very great person with highest level of precision or else something is really wrong.
What is your take on this?
Project Management is not dependent on a highly costly and good quality tool. Projects can be managed without any tools too, in a simplistic manner, if one has the art to manage them. But definitely tools do help in optimizing management of projects by various means. Any tool that intends to be qualified as a good Project Management Tool must have some very basic features of qualities mentioned as below:
1. Good Interface.
2. Simple to Use, effective usability.
3. Capable of Collaborating various teams engaged in project management.
4. Setting of Goals, managing and tracking them with an alert/ escalation workflow. Searching and managing goals
needs to be quite simple and effective.
5. Team Activity visible and manageable at respective levels.
6. Web Based is must, mobile version is cherry on the cake.
Bob was a highly paid development engineer in a U.S. company. Somehow he got addicted to certain social media activities on internet to an extent that without compromising with his job he found out a dangerous way of getting the job allocated to him by bypassing his organization’s security guidelines. Bob (name changed) was caught quite later when the internet and access data was audited in his company, as per the report published recently What Bob did to get plenty of time to browse through the websites of his choice and spend time there is quite interesting but not be repeated by anyone during his/ her carrier.
Bob was getting a hefty amount of salary for his development skills. He found out some dirt cheap developers in China and engaged them in doing his development work in his behalf by logging into his organization’s network remotely. While these developers in China were performing Bob’s job, Bob used to be busy in various sites like LinkedIn, FaceBook, eBay, Reddit etc. But at the end of each day, he never skipped updating his management on tasks completed for the day (which actually were being done by his Chinese counterpart hired by him at at the rate of peanuts).
It was an exception got caught during an audit of network in Bob’s company where it was found that everyday during working hours a remote connection is established from somewhere in China from a fixed location and from there further analysis explored Bob’s everyday activities on internet that brought him in the circle of doubts.
Vanessa Fiordio is known to be a an exhaustive learner from videos posted on YouTube. She spends a lot of her time on YouTube which is her best pass time. Her latest blog speaks on Managing Projects in Gangnam Style.
This seems to be a quite interesting blog/ article where she elaborates on various means of managing your project, getting highly inspired by Gangnam videos on YouTube.
Though you will find ample amount of templates online with the help of a simple Google search for “Defect Report” or “Bug Report” online, but still some of the components are must to have for any kind of Defect Report. Those essential ones are:
1. Scope of testing is important to be highlighted on the top of your Defects Report. If you miss this important information to be posted on the top of your report, it would probably not be able to suffice its purpose in terms of clarity and completeness to the respective stakeholders. Even if you being a part of test team would not be able to ascertain anything critical or important if you look at your own report released without this important factor clearly mentions.
2. Test bed/ test setup/ test environment is required to be clearly stated.
3. Schedule of testing and actual period of testing too are important to be mentioned.
4. Composition of test team is also required to be a must have component of your defects report.
5. Test Plan, Test Cases and Test Scenarios have to be there in as much detail as possible.
Collaborating with second and third party vendors has given a new twist to the life of not only to Nintendo, a major games development company, but also of the small companies engaged with the Nintendo. This is new pattern of collaboration with smaller development comapnies that Nintendo has emerged with. There are talented development teams which are smaller in size and hence even after having higher volume of talent pool with them are not ready to take larger risks.
That is where Nintendo has come into the picture by tying collaborative knots with these second and third party vendors to develop highly versatile network/ online/ IP based games.
This is called performing a project in a evolutionary manner and creating an win-win situation for all involved.
Delays in projects do happen. Sometimes with reasons within control and sometime beyond control. A proactive approach, hence, is always preferred so as to avoid a big disaster at a later stage of project nearing completion. The later is the disaster, the higher is the impact. Severity or the risk increases with the increase in phases of a project.
Some interesting factors during product development that become a sure shot in delay of a project are:
1. Lack of understanding of customer requirement.
2. Lack of documentation of above and getting it vetted by customer before diving in the pool.
3. Lack of Planning, scheduling monitoring and controlling.
4. Lack of adjusting customer changes coming during the development.
5. Lack of documentation at various stages.
Testing is a more serious job than coding. If there is a flaw in coding, tester is there to take care of it but there remains a flaw in your testing it is the customer that is going to shave off your head that too sometimes in a very bad manner depending on the severity of bugs or loopholes left in the product, bypassed by testing team and handed over to the customer.
Some basic things to avoid this which a tester can do are:
1. Run thoroughly through customer requirement. A small glitch/ ambiguity/ shortfall in CRD (customer requirement document) must of voiced in loudest of the tone so as to get clearest of the clarity. A careless bypass here might create a huge blunder at a later stage sometimes destroying the whole empire.
2. Strong in Querying gives you an extra edge otherwise for small queries you will have to depend on your programmers and that way they may try to misguide you in getting their coding passed falsely knowing your technical weakness.
3. Build your test cases looking at the product in a broader manner. Don’t hesitate to build thousands of test cases if there is a demand for that and an exhaustive testing is the requirement.
4. Perform testing on the product with two perspectives in mind – One, be as critical (constructively) as possible to drill down the minutest of the bug in coding; Two, Become customer while testing.
5. Report is as important as testing. If testing is done properly and that does not reflect in report – testing may go waste. Report has to be clear, crisp and simple.
Without preparing any background let us admit that a developer is prone to create bugs in the code he or she creates irrespective of volume/ length/ size or type of code. Though this reduces with the increase in experience but that is not a straight line formula in all cases. The mindset of a developer remains same that is build right since beginning and it becomes very difficult for a developer to get out of that mindset even after knowing the shortfalls of staying in that frame of mind while coding.
Let us look at some of the interesting factors that if avoided can prevent a developer becoming a devil programmer meaning getting into bug creation mode while writing his or her code:
1. Never write code with a misguiding factor that you are a supreme creator. It is not so. Avoid careless coding and think twice from different perspectives before finalizing your code and handing it over to testing team.
2. Try understanding the critic character in a tester that makes him a good evaluator and assessor of code thereby finding good amount of bugs.
3. Look at the way a tester goes into the shoe of the customer for which this coding is being done and then tasting the pudding the way customer would be in his day to day life while using this product.
4. Stop fearing from tester. There is always a fear of getting caught by Testing team and that fear sometimes generates bugs while coding.
5. Stop thinking of travelling the same road while coding. Think differently even for the same set of coding and that will give you a different kind of perspective.
6. Stop coding without documentation. That is a killer. That is merely a suicide.
7. Perform testing once your coding is done at your end before straightaway handing it over to testing team.
8. Stop becoming a victim of over tight schedules and thereby cooking half cooked food.
It rarely happens that any of the project phase finishes as per the stipulated plan. Due to one reason or the other, the planned tasks somehow get delayed and at times Project Manager is not able to anticipate this risk in advance. A way of moving towards perfection for a project manager would be to become able to anticipate risk of time delays in project well in advance and next step to it would be right sizing of project timelines including each and every task of the project.
Planning of timeline for an activity is based on experience, gut feel and some kind of objective measures. Overall if you see, for any activity, 50% is usually the accuracy level of it going right. Generally it is an underestimation (and rarely an overestimation) which if fluctuates high, sometimes, goes takes project out of control and becomes a major reason for its failure. Howsoever realistic a project manager becomes while defining project timelines for individual tasks which are part of different phases of a project, it skips certain micro level measure of timelines and hence deviates from producing and projecting a highly accurate plan. Being slightly over enthusiast at the time of projects also diverts you from leading to a 100% accurate plan.
Struggling to produce accurate estimation of certain task of a project also indicates that there is some lack of clarity in components of the task in question thereby inviting more of gut feel and speculation that leads to guess work rather than staying on the right track and producing something near to accurate timelines.
Three days back one of the world’s top company engaged in project management training – ESI International – has officially released in a press conference – Top Ten Trends in Project Management for 2013. ESI belongs to its parent company Informa Plc, and is engaged in providing highly focused training in project management all across the globe. They engage their customers during training them on project management through innovative training techniques that help them in optimizing and improving their ways of project, contract, customer requirement, and vendor management in a better and objective manner.
Over a period, ESI has been providing more than 100 specialized courses in almost 15 languages in more than 100 cities all across globe and has its headquarter in Arlington, Va., USA. As per their press release, by now they have trained over 1.35 million professionals in project management all across the globe. According to the trends there is a tremendous lack of leadership expertise in all fields of project management. The same was quoted by EVP, ESI International, J. LeRoy Ward stating “”Leadership skills are lacking within the project community, and until project managers learn how to properly lead teams and their projects, project execution will continue to be a problem.”
My interpretation of those 10 top trends is as below (the original trends declared by ESI International can be read by clicking here):
1. Organizations will keep fooling themselves by seeking strong project leaders but their major priority will
still lie on investing in hard skills. Poor organizations will ignoring soft skills in leaders?
2. Organizations adopting Agile Methodologies for project management without understanding its core values,
process and purpose will be prone to fail in their implementations.
3. Organizations that still think that project management is the ball game of only project manager will go
outdated faster unless they change their thinking.
4. Big sized projects pose different and big sized hurdles which become tougher to mitigate. But still Big
Projects do success in real life.
5. Major responsibility of PMO should only be promoting (by walking the talk even, if required) innovative techniques in conquering risks during project management. This will be the only way PMO will be able to prove its worth.
6. Level of PM certification will have to be increased by the U.S. government in order to do away with increasing condemnation all across.
7. Project managers will have to spread their wings and will have to upgrade themselves in management of vendors.
8. Project failures should result in termination of PMO as the sole accountable group with no other set of responsibilities.
9. With increasing count of projects and high pressure in project cost optimization (reduction), higher amount of focus will go on enhancement in role of portfolio management.
10. Organizations having a mindset of adopting Agile for the purpose of increasing project launch in production if succeed will have an amazing learning with them that will minimize their further chances of failures in future projects.
This is a lovely video found on Youtube. It talks about some basic fundamentals of project management in a very simple manner but conveying the message very clearly and crisply. Nothing much to say about what is there in this video. Just watch this less than 4 minutes video and take along all important points to be practiced in real life scenario.
First you look at this video and enjoy it. The beginning might frighten and worry you to see baby penguins caught in severe snowfall and low temperature and probably lost their way too. But gradually at the end they reached into safe hands. That gave a big sigh of relief and all worry goes off.
Is is not that similar kind of situations arises with project team during project management. The team feels, all of a sudden, quite low and lost; like small young penguins, wondering where are the elder penguins gone. Why is there no elder penguin to guide towards the right path?
You have paid a good amount of money to procure an excellent project management tool. This would have started with the identification of need of a project management tool after which you convinced your management and got an estimated budget approved for its procurement. Once the need is identified and approved by top management, next step also has been well taken care by you, by mapping it with the existing world class tools available in the market (or web) and zeroing down to the best of the lot.
Once procured, a special training has also been done on the tool along with extensive hands on for identified core team in the organization that would be working the tool to draw out best results regarding all projects running and required to be monitored and controlled on this tool. So far so good. But what about using all functionality and features available in this tool. Features would include sharing of files, collaborating, monitoring, task management, tracking, time management and or finance control on various/ some or all activities of a project.
An overall control is possible only if all important functionality and features available in project management tool are used efficiently. On top of it, if this tool gets integrated with various legacy or mainstream business applications in use in the organization, for sending or writing back important piece of information to be shared across various apps, it would be great. It helps a lot in monitoring and controlling of project across all relevant functions and stakeholders.
A standalone project management tool might not be able to cater to all relevant functions like finance, operations, PMO, logistics etc. And even if it; it would be asking for lot of duplicate entries that would be there as origin level entries at various points in various other applications. These other applications might be the legacy applications in use because of the unique functionality they are catering to, or the newly implemented main/ core business application covering most of the business functions.
Whatsoever is the case, entry of same kind of information in two or three places again not only takes away lot of efforts and time but also invite errors while entering the same data at various places. That is the purpose that if the data is available in any other applications – be it legacy or core business application like ERP, it is important to integrate it with your project management tool by building an interface or web services for the purpose of pushing or pulling; writing to or writing back; all identified important pieces of information. If need be, and if specified by security norms in the organization, for interfaces, encryption and decryption can be deployed depending on the severity of information flowing from one database to another.