Luc Richard writes in an article for ProjectSmart:
"Must project managers be technically savvy? This topic always seems to cause quite a stir. While some believe that all you need to manage a project is a PMP certification, others are convinced that you can't successfully manage a software development project unless you truly understand the intricacies of the product.
I agree! To be an effective project manager, you must know the ins and outs of your solution. You must be capable of designing and developing the solution yourself."
I do not agree that project manager's need to have the technical know-how on specialized products. What becomes of working in a project team and the sourcing of expert advice when needed. It may just be this know-all attitude that may result in a failed project.
To be a successful project manager requires an understanding of the methodologies of project management, for eg. scheduling, estimating, resource allocation, risk, communication, quality etc. , and be a strong communicator. It also requires the ability to motivate project team members towards excellent, and using the best ideas for project success.
I would agree with Richard's that knowledge of product or required end result is important, but not to the expert level he suggests.
Read Richard's full article at:
Must-project-managers-be-technically-savvy.html
Tuesday, June 28, 2011
Friday, June 24, 2011
Whistler, BC, Canada
Whistler is one of my favorite places during winter. Apart from all the activities, the scenery is amazing.
Wednesday, June 22, 2011
Don't get stuck in the Cloud
Cloud computing offers a value proposition based on convenient services that you pay for as you go. Customized solutions can be offered in a flexible and secure environment. Companies can offload their non-core technologies and focus on their core businesses, providing a better product for their customers.
But cloud computing is based on the premise that users will always have access to the cloud service. Managers need to ask themselves what would happen if the service were unavailable. What if the cable from their internet provider were cut or — as has happened with alarming frequency lately — the service were disrupted by hackers or technical glitches?
The key issue is access to the data. Servers and technology can be found at secondary sites, but if the data is locked in the cloud, the business's ability to function may be severely compromised. On my plane, which had no Wi-Fi, I was without access to the source data. The format of the data on the Kindle probably wasn't compatible with other devices, even if I could have extracted it and the software licenses had allowed it. I did have the data (the book) on my iPhone, but reading a book on an iPhone screen didn't appeal to me and I had no way to connect the phone to the iPad.
Cloud computing is the future. It is winning over entire industries — including traditional late adopters such as health care. The keys to success are careful planning of a migration strategy and understanding that the cloud approach is adolescent in places (remember the early days of the internet?) and that problems will occur. If you're still window shopping, it's time to start catching up on your reading about the cloud. But if you do so on a plane, remember to take a real book along, too.
Read full article by Robert Plant for HBR:
Dont_get_stuck_in_the_cloud.html
But cloud computing is based on the premise that users will always have access to the cloud service. Managers need to ask themselves what would happen if the service were unavailable. What if the cable from their internet provider were cut or — as has happened with alarming frequency lately — the service were disrupted by hackers or technical glitches?
The key issue is access to the data. Servers and technology can be found at secondary sites, but if the data is locked in the cloud, the business's ability to function may be severely compromised. On my plane, which had no Wi-Fi, I was without access to the source data. The format of the data on the Kindle probably wasn't compatible with other devices, even if I could have extracted it and the software licenses had allowed it. I did have the data (the book) on my iPhone, but reading a book on an iPhone screen didn't appeal to me and I had no way to connect the phone to the iPad.
Cloud computing is the future. It is winning over entire industries — including traditional late adopters such as health care. The keys to success are careful planning of a migration strategy and understanding that the cloud approach is adolescent in places (remember the early days of the internet?) and that problems will occur. If you're still window shopping, it's time to start catching up on your reading about the cloud. But if you do so on a plane, remember to take a real book along, too.
Read full article by Robert Plant for HBR:
Dont_get_stuck_in_the_cloud.html
Monday, June 20, 2011
Is it 'us vs. them' or 'all together now'?
Great article by Paul Glen for Computerworld.
Over the years, I've noticed the power that a few simple words have to determine how project teams relate to their sponsors: "client," "customer," "we," "us," "them" and "partner." It's odd how little attention is paid to these words, given the critical role that the relationships they describe play in the success or failure of projects.
As a consultant helping to launch new projects or turn around troubled ones, I listen carefully for these words, because they tell me all I need to know about the relationship between project team and sponsor. When I hear "client," "customer," "us" or "them," I know that the team is working in a transaction mode. "Partner" and "we" indicate that they are in a relationship.
Relationship mode has only team members, not opponents. The team members represent different functional areas, but they are ultimately part of a collective. They jointly define common goals and expected standards of behavior. Together, the team members work to balance the common goals they commit to and the goals of each functional area that the members represent. The balancing act is more collaborative. Information is handled more transparently, and problem-solving is a joint effort. Together, the team places a higher priority on maintaining the long-term relationship, since they expect to continue working together after the completion of the project.
While each mode has advantages and disadvantages, relationship mode tends to yield better results and lead to a better work environment for everyone involved. Teams in relationship mode find motivation in their commitment to one another. When the dynamic is transactional, the participants find motivation outside the team. Teams committed to their buddies are more steadfast than ones devoted to a concept or a distant client.
So before you automatically start calling your sponsor your "client," give the relationship some serious thought. One little word at the beginning of the project can make a huge difference.
Read full article at:
Is_It_Us_vs._Them_or_All_Together_Now
Over the years, I've noticed the power that a few simple words have to determine how project teams relate to their sponsors: "client," "customer," "we," "us," "them" and "partner." It's odd how little attention is paid to these words, given the critical role that the relationships they describe play in the success or failure of projects.
As a consultant helping to launch new projects or turn around troubled ones, I listen carefully for these words, because they tell me all I need to know about the relationship between project team and sponsor. When I hear "client," "customer," "us" or "them," I know that the team is working in a transaction mode. "Partner" and "we" indicate that they are in a relationship.
Relationship mode has only team members, not opponents. The team members represent different functional areas, but they are ultimately part of a collective. They jointly define common goals and expected standards of behavior. Together, the team members work to balance the common goals they commit to and the goals of each functional area that the members represent. The balancing act is more collaborative. Information is handled more transparently, and problem-solving is a joint effort. Together, the team places a higher priority on maintaining the long-term relationship, since they expect to continue working together after the completion of the project.
While each mode has advantages and disadvantages, relationship mode tends to yield better results and lead to a better work environment for everyone involved. Teams in relationship mode find motivation in their commitment to one another. When the dynamic is transactional, the participants find motivation outside the team. Teams committed to their buddies are more steadfast than ones devoted to a concept or a distant client.
So before you automatically start calling your sponsor your "client," give the relationship some serious thought. One little word at the beginning of the project can make a huge difference.
Read full article at:
Is_It_Us_vs._Them_or_All_Together_Now
Project teams and 'the avoidance collusion'
Great article by Paul Glen which addresses the phenomenon of avoidance as a commonality in project teams. Avoidance may be more prevalent in functional structured organizations where project team members are added to a project, not having the project as main concern because it is an additional task to their employment.
Sometimes it feels as if our basic assumption about project leadership teams is that they can't work well together -- as if collaboration is out of the question and we're ready to settle for a cold peace based on limited communication and mutual suspicion.
The prototypical project leadership team consists of a project manager, a technical lead and a business sponsor. Their relationships form the core of the project culture, which spreads out to the rest of the team. If the core group works well together, displays patience and respect for one another, adopts common goals, and trusts one another, the rest of the team tends to interact accordingly. If they treat each other with legalistic caution and reserve, that too spreads throughout the team. The tone is set in that core.
The three people who fill these roles tend to be very different from one another. They represent the interests of dissimilar parts of the organization and have different educations and professional experiences, which give rise to distinctive assumptions about how businesses should work and even different ways of talking. And they tend to have rather divergent behavioral styles -- styles that reflect the very different departmental cultures they represent.
But they do have at least one thing in common -- though it seems to undermine their collective collaboration. That one thing is what I call "the avoidance collusion," which stems from the fact that none of them is terribly concerned about his relationships with the other two.
Read this excellent full article by Paul Glen for Computerworld:
Projects_and_Avoidance
Sometimes it feels as if our basic assumption about project leadership teams is that they can't work well together -- as if collaboration is out of the question and we're ready to settle for a cold peace based on limited communication and mutual suspicion.
The prototypical project leadership team consists of a project manager, a technical lead and a business sponsor. Their relationships form the core of the project culture, which spreads out to the rest of the team. If the core group works well together, displays patience and respect for one another, adopts common goals, and trusts one another, the rest of the team tends to interact accordingly. If they treat each other with legalistic caution and reserve, that too spreads throughout the team. The tone is set in that core.
The three people who fill these roles tend to be very different from one another. They represent the interests of dissimilar parts of the organization and have different educations and professional experiences, which give rise to distinctive assumptions about how businesses should work and even different ways of talking. And they tend to have rather divergent behavioral styles -- styles that reflect the very different departmental cultures they represent.
But they do have at least one thing in common -- though it seems to undermine their collective collaboration. That one thing is what I call "the avoidance collusion," which stems from the fact that none of them is terribly concerned about his relationships with the other two.
Read this excellent full article by Paul Glen for Computerworld:
Projects_and_Avoidance
Thursday, June 16, 2011
Nine Common Project Estimating Pitfalls
There are many things that can undermine the accuracy or validity of your estimates. Some you have control over and many that you can’t really control. Here are nine common pitfalls that can often negatively impact project estimates:
Poorly defined scope of work. This can occur when the work is not broken down far enough or individual elements of work are misinterpreted.
Omissions. Simply put, you forget something.
Rampant optimism. This is the rose-colored glasses syndrome, when the all-success scenario is used as the basis for the estimate.
Padding. This is when the estimator (in this case almost always the task performer) includes a factor of safety without your knowledge, a cushion that ensures that he or she will meet or beat the estimate.
Failure to assess risk and uncertainty. Neglecting or ignoring risk and uncertainty can result in estimates that are unrealistic.
Time pressure. If someone comes up to you and says, “Give me a ballpark figure by the end of the day” and “Don’t worry, I won’t hold you to it,” look out! This almost always spells trouble.
The task performer and the estimator are at two different skill levels. Since people work at different levels of efficiency, sometimes affecting time and cost for a task significantly, try to take into consideration who’s going to do the work.
External pressure. Many project managers are given specific targets of cost, schedule, quality, or performance (and often more than one!). If you’re asked to meet unrealistic targets, you may not be able to fight it, but you should communicate what you believe is reasonably achievable.
Failure to involve task performers. It’s ironic: an estimate developed without involving the task performer could be quite accurate, but that person may not feel compelled to meet the estimate, since “it’s your number, not mine,” so the estimate may appear wrong.
Article by Brad Egeland, a seasoned project management professional:
Nine-common-project-estimating-pitfalls.html
Poorly defined scope of work. This can occur when the work is not broken down far enough or individual elements of work are misinterpreted.
Omissions. Simply put, you forget something.
Rampant optimism. This is the rose-colored glasses syndrome, when the all-success scenario is used as the basis for the estimate.
Padding. This is when the estimator (in this case almost always the task performer) includes a factor of safety without your knowledge, a cushion that ensures that he or she will meet or beat the estimate.
Failure to assess risk and uncertainty. Neglecting or ignoring risk and uncertainty can result in estimates that are unrealistic.
Time pressure. If someone comes up to you and says, “Give me a ballpark figure by the end of the day” and “Don’t worry, I won’t hold you to it,” look out! This almost always spells trouble.
The task performer and the estimator are at two different skill levels. Since people work at different levels of efficiency, sometimes affecting time and cost for a task significantly, try to take into consideration who’s going to do the work.
External pressure. Many project managers are given specific targets of cost, schedule, quality, or performance (and often more than one!). If you’re asked to meet unrealistic targets, you may not be able to fight it, but you should communicate what you believe is reasonably achievable.
Failure to involve task performers. It’s ironic: an estimate developed without involving the task performer could be quite accurate, but that person may not feel compelled to meet the estimate, since “it’s your number, not mine,” so the estimate may appear wrong.
Article by Brad Egeland, a seasoned project management professional:
Nine-common-project-estimating-pitfalls.html
Project Management Best Practices
- Quicker ramp-up of project managers
- Easier integration of projects in a multi-project environment
- More productive project managers (not inventing processes and tools on the fly)
- Equips project managers with tools to “fill the gaps” in the client environment
- Better overall team performance – delivering on customer expectations (including measurement of performance)
Read the full article by Steve Hart for PM Foundations:
http://pm-foundations.com/2011/06/11/top-6-project-management-best-practices/
Wednesday, June 8, 2011
Successful Facilitation
When major disagreements arise within an organization, a facilitator is sometimes needed to help work things out. A facilitator is one who works with a group of people to help make it easier to resolve a situation. Facilitation is very beneficial because issues are discussed thoroughly. Problems are often solved at the root level–not just on the surface. Team members are able to discuss and create plans as experts.
During each facilitation meeting, there is always a clear direction or objective. There is a lot less “rabbit chasing” and a more focused approach to the topic. The facilitator works to involve everyone into the conversation. The facilitator also ensures that all decisions are carried out and supported after the meeting has ended.
The facilitator’s role during each session is important to keep everything on track. He or she must have strong communication skills and the ability to expose the real issue at hand while remaining neutral. Negotiation skills are a must when coming to a consensus with which everyone can agree. Patience is a virtue when it comes to facilitation. He or she must avoid going for the quick solution to the surface problem rather than dealing with the root problem. Keeping balance during the meeting is necessary so that everyone’s voice can be heard and not attacked. He or she must be prepared to guide the meeting with a plan and structure.
There are also a few things, however, that can lead to a facilitator’s downfall or discredibility.
- Allowing people to run over each other
- Forgetting to verify group’s decision
- Showing a lack of active listening
- Pushing his/her own opinions
- Ridiculing ideas and options
- Demonstrating no assertiveness
- Discussing a topic too long
- Making jokes on very serious topics
Successful-facilitation
Monday, June 6, 2011
History of Project Management
An interesting read by Merry Barron and Andrew R. Barron for PM Hut.
Could the Great Wall of China, the pyramids, or Stonehenge have been built without project management? It is possible to say that the concept of project management has been around since the beginning of history. It has enabled leaders to plan bold and massive projects and manage funding, materials and labor within a designated time frame.
Project management in its present form began to take root a few decades ago. In the early 1960s, industrial and business organizations began to understand the benefits of organizing work around projects. They understood the critical need to communicate and integrate work across multiple departments and professions.
The Project Management Institute (PMI) was founded in 1969 by five volunteers. Their initial goal was to establish an organization where members could share their experiences in project management and to discuss issues. Today, PMI is a non-profit project management professional association and the most widely recognized organization in terms of promoting project management best practices. PMI was formed to serve the interests of the project management industry. The premise of PMI is that the tools and techniques of project management are common even among the widespread application of projects from the software to the construction industry. PMI first began offering the PMP certification exam in 1984. Although it took a while for people to take notice, now more than 260,000 individuals around the world hold the PMP designation.
Read the full article at:
History-of-project-management
Could the Great Wall of China, the pyramids, or Stonehenge have been built without project management? It is possible to say that the concept of project management has been around since the beginning of history. It has enabled leaders to plan bold and massive projects and manage funding, materials and labor within a designated time frame.
Project management in its present form began to take root a few decades ago. In the early 1960s, industrial and business organizations began to understand the benefits of organizing work around projects. They understood the critical need to communicate and integrate work across multiple departments and professions.
The Project Management Institute (PMI) was founded in 1969 by five volunteers. Their initial goal was to establish an organization where members could share their experiences in project management and to discuss issues. Today, PMI is a non-profit project management professional association and the most widely recognized organization in terms of promoting project management best practices. PMI was formed to serve the interests of the project management industry. The premise of PMI is that the tools and techniques of project management are common even among the widespread application of projects from the software to the construction industry. PMI first began offering the PMP certification exam in 1984. Although it took a while for people to take notice, now more than 260,000 individuals around the world hold the PMP designation.
Read the full article at:
History-of-project-management
Sunday, June 5, 2011
Windows 8 looks impressive
I changed to Ubuntu Linux over a year ago, and running on Ubuntu 11.04 at the moment. I just took a look at the new Windows 8 and it looks pretty impressive.
Thursday, June 2, 2011
Avoid the Agile Logjam
Bill Krebs looks into the importance of team dynamics and team commitment as a key success factor in Agile oriented projects in his article for Voices on Project Management.
Not all Agile teams are created equal.
Some commit to their work and complete requirements throughout -- not just at the end.
Other teams struggle. Their sub-tasks may make progress, but their overall requirements or "stories," which express requirements in ways that customers can relate to, seem to get stuck. They finish on the last day of the iteration, if at all.
What makes these teams different?
Often requirements haven't been sub-divided. Queuing theory teaches that the same amount of work divided into smaller pieces flows faster. Teams with stories divided into work durations of one to three days see their work fly through the system. They can finish some requirements and then pick more.
Teams with stories that take a week or more are at risk of a traffic jam. Moreover, we're less aware of the delay until later -- when it's harder to take corrective action.
One correction is to refocus on a smaller number of requirements, but dedicate to finishing those. Another method is to split a story, even though the iteration is underway. Or, remove a story from the current iteration so it can be fully completed in another.
If none of these ideas seem enough, make sure the team is committed. Per the principles in the Agile Manifesto, team members need to self-organize to dedicate themselves to finishing whatever work is planned.
Not all Agile teams are created equal.
Some commit to their work and complete requirements throughout -- not just at the end.
Other teams struggle. Their sub-tasks may make progress, but their overall requirements or "stories," which express requirements in ways that customers can relate to, seem to get stuck. They finish on the last day of the iteration, if at all.
What makes these teams different?
Often requirements haven't been sub-divided. Queuing theory teaches that the same amount of work divided into smaller pieces flows faster. Teams with stories divided into work durations of one to three days see their work fly through the system. They can finish some requirements and then pick more.
Teams with stories that take a week or more are at risk of a traffic jam. Moreover, we're less aware of the delay until later -- when it's harder to take corrective action.
One correction is to refocus on a smaller number of requirements, but dedicate to finishing those. Another method is to split a story, even though the iteration is underway. Or, remove a story from the current iteration so it can be fully completed in another.
If none of these ideas seem enough, make sure the team is committed. Per the principles in the Agile Manifesto, team members need to self-organize to dedicate themselves to finishing whatever work is planned.
Subscribe to:
Posts (Atom)