Have you ever wondered about …… What exactly does the ‘scope of a project’ mean? …..I have…. I kept on hearing this term from the time when I started my career. Though I have learned its meaning over the years; people around me still describe the term vaguely. Thus, I am going to provide you with some simple tips, which can help you to clearly define the scope for your project.
The deliverables: Let’s say, you are one of those project managers whose projects are very complex, and you don’t know where exactly to start for defining the scope of your project. If you are not sure about how to move forward with this process then you should at least try to define the deliverables of the project. Don’t stress yourself too much. Ask your customers to provide you with tangible (I mean tangible) deliverables that they would like to see at the end of the project. Once, you figure out the final deliverables of the project, you can then go ahead and try to define the interim project deliverables. These defined deliverables will tremendously help you to better understand the project.
Project boundaries: Once you got some handle on how the project should look like through its deliverables, you should now define how it shouldn’t be looking. For example: Chris is going to look for a software third-party provider within the US. In this case, third-party software providers from China are out of scope. If Chris was considering the needs of the entire global company, this would not have been a good boundary statement since he could not have stated a good out-of-scope statement.
Project Features: Once you have described the deliverables and the boundaries, you have completed high-level scope. Now, it’s time to describe the physical characteristics of the deliverables, called features. If you were building a software framework, for instance, most of the functionalities would count as features. These might include the number of GUIs (graphical user interface), number of APIs (application interface), etc. So, follow the top-down approach and start defining project’s features from its well defined deliverables.
Project Functions: Once you finished describing project’s features, now you need to describe how people interact with a deliverable and how a deliverable interacts with other deliverables. For example, if you need to change invoicing and billing transactions, most of the requirements could end up being process oriented. This would include how billing transactions move from orders to invoicing to accounts receivable. Basically you are defining the information flow in this phase. Thus, make sure to involve all the stakeholders, who will be affected by this information.
I hope these simple tips will help you to better define the scope of your project. Let me know, if you have any other ideas through which you can make this process simpler. Thanks. – Bhavin Gandhi.
|
Showing posts with label Project Management. Show all posts
Showing posts with label Project Management. Show all posts
Monday, July 2, 2012
How to clearly define the scope of your project?
Thursday, June 2, 2011
Practical solutions to reduce time barriers between your Virtual Teams
I have seen various virtual teams that fails to accomplish their mission due to lack of communication. Virtual teams have many challenges like culture differences, language barriers, lack of personal touch, etc. But the ‘time difference’ is one of the most important challenge that a virtual team faces. As a part of my existing job, I manage various individuals from 3 completely different locations. And I have faced similar situations while managing these individuals. Through my experience, I have developed few practical solutions to resolve these challenges, and I would like to share those tips through this blog.
Define rigid working hours: I am neither a micromanager nor I believe in monitoring my people. But sometimes it is very crucial for a team to follow a strict schedule. Asynchronous communication channels like SMS and e-mails will only resolve few issues. But if you are working in a fast paced environment like me (Agile or Scrum approach), then it becomes very difficult to communicate through these asynchronous channels of communications. This approach makes it possible for me to meet with each and every individual at least 2 times a week (through video conference). From past few months, my team in China comes early every 2 days during the week and my team in USA stays late for those 2 days. This arrangement makes it easier to work with these people and it also helped me to increase my team morale.
Establish rules for e-mail communications: In the past, I have been in various situations when I will get an e-mail from my China team at around midnight in my time zone, and I won’t have any opportunity to reply to them until the day after. Thus, if you are working in a virtual team then you should be establishing few rules for your e-mail communications. For example: Tell your remote team in China to notify you regarding any urgent issues/concerns before midnight your time. Obviously, they will not be able to identify all the issues every time before you go to sleep, they might encounter few problems after you go to sleep. In that case, make sure that you always task them with some kind of other work, which is independent from that particular task. This will give them something to work on, before you can actually resolve their problem. This approach had helped me tremendously to increase the productivity of my team.
Make information go public: In most of the cases, people depend on each other for the information. Most of the professionals will take an educated decision in a given situation, if they were provided with the appropriate information. I made most of my information public in such a way that my team can have access to that information all the time. For example: during every meeting, I take meeting notes and prepare a list of action items. I started putting that information to our SharePoint site. This helped my team to have a baseline information and having the right information in their possession. This approach has reduced long chain of e-mails to get the same information that they would have got otherwise.
I hope, these tips will help you to reduce various time and communication related challenges with your virtual teams. Please feel free to comment on my blog, if you have any other suggestions for improving efficiency of your virtual teams. Thanks. – Bhavin Gandhi
Define rigid working hours: I am neither a micromanager nor I believe in monitoring my people. But sometimes it is very crucial for a team to follow a strict schedule. Asynchronous communication channels like SMS and e-mails will only resolve few issues. But if you are working in a fast paced environment like me (Agile or Scrum approach), then it becomes very difficult to communicate through these asynchronous channels of communications. This approach makes it possible for me to meet with each and every individual at least 2 times a week (through video conference). From past few months, my team in China comes early every 2 days during the week and my team in USA stays late for those 2 days. This arrangement makes it easier to work with these people and it also helped me to increase my team morale.
Establish rules for e-mail communications: In the past, I have been in various situations when I will get an e-mail from my China team at around midnight in my time zone, and I won’t have any opportunity to reply to them until the day after. Thus, if you are working in a virtual team then you should be establishing few rules for your e-mail communications. For example: Tell your remote team in China to notify you regarding any urgent issues/concerns before midnight your time. Obviously, they will not be able to identify all the issues every time before you go to sleep, they might encounter few problems after you go to sleep. In that case, make sure that you always task them with some kind of other work, which is independent from that particular task. This will give them something to work on, before you can actually resolve their problem. This approach had helped me tremendously to increase the productivity of my team.
Make information go public: In most of the cases, people depend on each other for the information. Most of the professionals will take an educated decision in a given situation, if they were provided with the appropriate information. I made most of my information public in such a way that my team can have access to that information all the time. For example: during every meeting, I take meeting notes and prepare a list of action items. I started putting that information to our SharePoint site. This helped my team to have a baseline information and having the right information in their possession. This approach has reduced long chain of e-mails to get the same information that they would have got otherwise.
I hope, these tips will help you to reduce various time and communication related challenges with your virtual teams. Please feel free to comment on my blog, if you have any other suggestions for improving efficiency of your virtual teams. Thanks. – Bhavin Gandhi
Friday, April 15, 2011
3 Simple Tips to Effectively Manage Customer Expectations in a Project
Unfortunately, I have been a part of numerous projects, where customers change their expectations in the middle of the project. I am sure that you must have been a part of similar situation during your career. I might not have a perfect solution for this problem. But in this blog, I will provide you with 3 simple tips that will help you minimize any change in your project due to changes in customer expectations.
Identify what your customers don't need:
In my experience, I have always found a "NOT TO DO" list very helpful. The list of things you will not deliver sets boundaries for your project, and it provides a comprehensive basis for scoping discussions with your users and customers. To define a "NOT TO DO" list, you can ask various questions to your customers, such as: What is of the least value to you? What if we don't deliver this component? What will be an acceptable project? Trust me, this approach will go a long way in defining the actual scope of your project.
Communicate ONLY realistic expectations:
During my career, I have been a part of numerous projects where expectations were unrealistic. Manager/Client will over promise to their customers/stakeholders to gain their business/trust, and they fail to realize that they will lose their credibility when they can't stand up to their expectations. Thus, I would suggest you to carefully define the scope of your project. If you suspect any infeasible components in your project, then investigate those issues before promising anything to your customers. If your investigation shows that something expected by your customers is probably impossible, then communicate your findings with them. In this way, you will earn their trust and gain some credibility by involving them into decision making. After all, it is always better for projects to under promise and over deliver than to do the reverse.
Revisit requirements often:
Those days are gone, when we used to have rigid requirements for our projects, which hardly ever changed. Today's Project Management is a whole new game. Though our project might not change, the external environment will change, which will in turn change the requirements of the project. Thus, I would recommend you to implement a continuous feedback loop in your project management lifecycle, and revisit your requirements often. You can use various mechanisms to do this, such as: ongoing project discussions with your customers; demonstration of prototypes, pilots, mock-ups, and intermediate deliverables; feedback from testing; and other periodic customer interaction.
I hope, these tips will help you to manage changes in your project due to change in customer expectations. Let me know, if you have any other suggestions regarding the same. Thanks. – Bhavin Gandhi
Identify what your customers don't need:
In my experience, I have always found a "NOT TO DO" list very helpful. The list of things you will not deliver sets boundaries for your project, and it provides a comprehensive basis for scoping discussions with your users and customers. To define a "NOT TO DO" list, you can ask various questions to your customers, such as: What is of the least value to you? What if we don't deliver this component? What will be an acceptable project? Trust me, this approach will go a long way in defining the actual scope of your project.
Communicate ONLY realistic expectations:
During my career, I have been a part of numerous projects where expectations were unrealistic. Manager/Client will over promise to their customers/stakeholders to gain their business/trust, and they fail to realize that they will lose their credibility when they can't stand up to their expectations. Thus, I would suggest you to carefully define the scope of your project. If you suspect any infeasible components in your project, then investigate those issues before promising anything to your customers. If your investigation shows that something expected by your customers is probably impossible, then communicate your findings with them. In this way, you will earn their trust and gain some credibility by involving them into decision making. After all, it is always better for projects to under promise and over deliver than to do the reverse.
Revisit requirements often:
Those days are gone, when we used to have rigid requirements for our projects, which hardly ever changed. Today's Project Management is a whole new game. Though our project might not change, the external environment will change, which will in turn change the requirements of the project. Thus, I would recommend you to implement a continuous feedback loop in your project management lifecycle, and revisit your requirements often. You can use various mechanisms to do this, such as: ongoing project discussions with your customers; demonstration of prototypes, pilots, mock-ups, and intermediate deliverables; feedback from testing; and other periodic customer interaction.
I hope, these tips will help you to manage changes in your project due to change in customer expectations. Let me know, if you have any other suggestions regarding the same. Thanks. – Bhavin Gandhi
Subscribe to:
Posts (Atom)