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.
|