For my research of a project management tool, I researched ActiveCollab. ActiveCollab is a project management tool targeted at smaller teams. It is mainly an online tool, but can be installed locally. A small team(5 members and 5GB of storage) costs $250 a year. There are many tiers after this, finally ending with an unlimited pricing option, which is $3,000 a year for unlimited members and 500GB of storage. Some of the main features of ActiveCollab include email integration, mobile applications, document version control and a desktop timer. With the email integration, you can get emails for comments on a task and reply to leave a comment. You can even create tasks through email. As with all software, you can create project and work packages within those projects. Then tasks and subtasks. Tasks can have date, be assigned to team members, be categorized, etc. You have a daily dashboard that displays all of the days relevant information. The is not much on the side of analytics, but basic charts and graphs are available. The tool is generally very easy to use and I believe it is a great tool for small teams. Being a cloud based application with limited, but easy to use functionality, a small team would be greatly serviced by this tool. For larger teams, this would not be a good tool. The feature set would be far too limited and does not come close to what is available in a product like Microsoft Project. Overall, ActiveCollab is a solid project management tool in the situations that it is targeted for. Check them out here.
Last week for class, we researched different online Kanban tools. To test them, I began to adapt the Kanban board to the workflow of my everyday life. I realized that a tool like this could be very useful in helping me organize myself. In the past, I have mostly relied on memory and random notes. I have carried daily planners, moleskins, written memos on my phone and on my computer, but have never been able to keep a centralized source of all the tasks I need to complete. This is especially true of long term activities. It is easy to write a post-it note for myself so that I will remember to complete and activity in the morning, but this does not work when it's something that needs to get done in the next month or so. I will simply lose the post it, forget about my memos, or it will get lost in my notebook. Using an online Kanban board could solve this problem for me. While testing, I created a simple Kanban board with Backlog, To-do, In-Progress and Done sections, going in that order form left to right. I began to put items into the backlog. I put in anything that I could think of, whether long- or short-term. I pulled the activities that I needed to complete that day into the to-do column, and eventually through the in-progress and done columns. This solution was already much easier than anything I have tried before. I was using the Leankit tool, which meant that I can access my kanban board online at anytime, or through my phone. I can add dates to activities, color code them and prioritize them. These are just three features of many. Going forward, I am going to try using this solution to organize the various personal activities that I need to complete.
A team war room is a space that a project team owns for the duration of the project. The point of a war room is to have a space that allows the team to reach their maximum productivity during their project. Everything they may need, e.g. white boards, computers, coffee, couches, are put into a war room during the design. Things like these eliminate any road blocks that lack of equipment of inability to communicate may bring up. I believe that when designing office space, it should always be thought of as a war room. If office space was designed in such a way that teams could set up their own war rooms, they would be much more productive. War room seem only to get set up during a time when maximum productivity is need. But if an office space can eliminate road blocks, great value should be placed into the design. Many small companies have office space like this, because they simply do not have enough people to have a traditional office space with separated cubicles and offices. An example of what I believe to be a great office space is Squarespace's office, seen below. The office is open and invites collaboration. There are white boards all around and people are always communicating. I saw a video of their office space in an article a while back, and the office space certainly breeds collaboration. If this type of office space was incorporated into modern office space for large companies, I believe it would help teams to be more successful.
In the world of tech today, there is an abundance of start-ups. Many fail to create a successful company, but there are many small companies that are changing the world right now. Many of these companies, though by no means all of them, are founded by young people with fresh ideas, willing to take risks. There are many reasons why Scrum is an effective project management style for them to adopt. One of the reasons is that in many scenarios, founders will have a solution to a problem but not an exact implementation. They need to start building a viable product before they can really know what needs to be done. They have no experience in the space. Scrum allows for a team to change course very easily, and easily assess the track that they are on. Another reason for using Scrum is that there are clear guidelines for how to implement Scrum. The Scrum Guide gives an outline of how to follow scrum within your team. Start-up founders tend to be younger and have less experience, especially in project management. Having a guideline to follow makes one less thing for them to worry about, so they can spend time worrying about their product, and not how to manage their product. There are many other reasons why Scrum is effective for start-ups, but those two are the reasons that have the biggest influence on the success or failure of a company.
As a project manager, you will sometimes be in a situation where you need to facilitate brainstorming sessions. These sessions may be held for a variety of reasons. For examples, you could be brainstorming solutions to a problem that has arisen with your product, brainstorming the cause of a problem, or having a creative session for new ideas. These are just a few of the possibilities. An exercise that can help these brainstorming sessions is to have the team create diagrams. One of these diagrams, which I believe is very effective, is an Ishikawa diagram, also known as a fishbone diagram. The goal of this diagram is to find the cause of a problem. You begin by drawing a problem, in a circle. From there you draw a long arrow to this bubble. Off of this arrow(or the spine of the fish) , you draw arrows off for each possible, most general categories that could be causing your problem. Then within each category you go down a level of generality and write possible causes. You may go down as many levels as you like, ideally until you find your root cause. Those these diagrams are used often to identify problems in a project, they are also very effective for product design. Reportedly, the Mazda Miata was designed using this diagram. You can find that there are usually high level causes for each industry that you can start with. For example, for the manufacturing industry they are manufacturing, material, method, man power, measurement and mother nature.
While working are my previous co-op, we used scrum. Our scrum master/team lead had a slightly different methodology, that I found interesting, for calculating the duration of the activities in our stories. It was based off of the idea that if you do general estimates for the activities, on average you will get accurate estimates. During our split planning, we would take our stories and split them into activities to complete the story, quickly adding a description of how they will get done. After that, we would go over each activity and people would throw out numbers for how long they think it would take to complete. The system that we used to manage our development allowed for time selections of 1/2/4/8/12/16/21/32. I am recalling from memory, so those numbers may be off by an hour or two. If there were different estimations, we would discuss why people made the estimation they did and why. This would never take more than a few minutes. Then we would come to a consensus, or go by majority rules. We would be able to go through this very quickly, so our sprint planning meetings were done in approx. 1 hour, for a two week sprint. Once someone started working on an activity, if it was taking more than a day they would update the activity times at the end of the day. So the estimates would get more accurate as the sprint went on. For us, this system seemed to work well. Though one problem that may arise because of it could be that people work on activities for as long as the estimates say. So if an activity was estimated at 8 hours, they would work on it for 8 hours no matter what. Though it may be that some activities get over-estimated and some get under-estimated, so some activities will get done faster, and some slower. This contributes to everything averaging out. It worked well for us and greatly optimized our workflow during our sprint planning.
Projects can be incredibly long and incredibly stressful. They may last years and can be incredibly high stakes. This puts a very high level of stress on a team. After dealing with all of this and finally finishing a project, a team has usually developed a great level of camaraderie between one another. They have also all grown as individuals and professionals. It can be hard for people to move on from something that has consumed such a large period of their recent life. This work must be celebrated for a few reasons. It must be known that the company values each worker and the contributions they are giving to the company. Also, this can help motivate employees going forward. Many times, core members of a team will stay together for multiple projects. So allowing the team to celebrate together can be an investment in the next project that they are working on. There are many ways to celebrate the end of a project. It can be something small like a pizza party, team tshirts, small gifts, thank-you notes, etc. Or it can be something larger, like bonuses or promotions. As a manager, these can be easy ways to show your team that you, and the company, appreciate them, and motivate them going forward.
After completing the development of the deliverables in a project, they must be installed for the client to use. There are four major approaches that can be taken, but it may not be obvious which one is most effective for your project. These are your options:
Phased Approach This approach means dividing the project into chunks that can be delivered separately. This solution is usually only appropriate when resources are not available to implement another solution. There may not be enough time or people to install the product in one go. Cut-Over Approach With the cut-over approach, everything is done in one swift motion. An old product is removed and the new product is installed. There are high stakes in this approach because the product must work correctly, immediately since the old product is no longer an option. In this scenario, it is always necessary to test the product in the exact environment that it will be installed in. This way you can be sure that the installation will go smoothly. This solution is fast and effective, but must be executed perfectly to work. Parallel Approach In this scenario, the deliverables are installed along side the old product. Both are in production at once. This option can be effective in a scenario where a product can not be effectively tested until installed for the client, or in a situation where the client is in the middle of important work that involves the old product. They can install the new product but still be able to use the old product for some period of time if they wish. By-Business-Unit Approach This approach means that the deliverables are installed one business unit at a time. This is another scenario commonly used when resources are a constraining factor. A company may not be able to afford to purchase the product all at once for an entire team/office/etc, so they will install them one, or a few, at a time as they get more money. In any project, there is guaranteed to be risk. And it is almost always guaranteed to manifest itself in your project in some way. An important part of a project manager's role is to keep potential risks from critically damaging a project. There are four main steps that a manager must take to stop this from happening:
-Risk Identification -Risk Assessment -Risk Mitigation -Risk Monitoring First you must identify the risks for your project. This is anything that could go wrong and harm your project. Four risk categories to look at are technical risk, project management risk, organizational risk and external risk. Make a list of all these risks. Next comes risk assessment. You and your team must discuss the risks and determine the likelihood of each risk occurring and the expected loss if the risk does materialize. Using these two numbers, you can rank risks. There are also many other ways to assess these risks that I will not go into detail about now. Then comes risk mitigation. This means planning what you will do with each risk if it materializes. There are 5 risk responses to consider: Accept, Avoid, Contingency Planning, Mitigate and Transfer. Finally you must monitor your risk. As the project goes along, you must keep track of the risks you identified, especially the important ones, and be aware if they begin to materialize. Sometimes, if you are not monitoring, they may materialize without you even knowing. Taking these four steps will allow you to keep risks, as much as possible, from potentially hurting your project. What exactly is project management? As defined in Effective Project Management, it is a set of tools, templates and processes designed to answer the following 6 questions:
What business situation is being addressed by this project? A situation will either be a problem or an untapped opportunity. This is why there are projects. As a manager you must know exactly what situation you are addressing so that you can effectively lead a project in a direction that addresses this situation. What does the business need to do? In some situations, a business may have a problem and there will be a clear solution to that problem, but in some situations, like in dealing with untapped opportunity, a business may not know exactly what they need to do. So in this case, knowing exactly what your business needs to do will manifest itself over time. Either way, you must document this so that you are aware of what is going to be done. What will you do? This should be answered when you determine your project goals and objectives. Your project overview statement will clearly document what you will be doing during the project How will you do it? How will will complete the objectives of the project can be determined either before started, or iteratively throughout the project. How will you know you did it? Your project should have business value to the company. So before setting out on your project, you should know exactly what criteria you will measure to determine whether or not you completed what you needed to. How well did you do it? Finally, you will measure how well you completed your objectives. There are 4 questions that you can look at to help you determine this: How well did your deliverable meet the stated success criteria, how well did the project team perform, how well did the project management approach work for this project and what lessons were learned that can be applied to future projects? You should be able to measure and take it as knowledge going forward to help you in future projects. |