Feature Announcement – Gantt Chart Report Released

February 17, 2013 By Anand Agarwal

2 Comments

A Gantt Chart is an excellent way to display and communicate project plan. It

  • Helps you to plan the tickets that need to be completed in the given milestone.
  • Gives you a basis for scheduling when these tasks will be carried out.
  • Allows you to plan the allocation of resources needed to complete the milestone and project.

When a project is under way, Gantt Chart helps you to monitor the progress of the milestone.

In 4.0 Release, we have added support for “Gantt Chart View” under Reports & Charts section.

Tickets are grouped by users and displayed in the “Gantt Chart View“. A ticket can be your task, feature, bug, or review task.  Color coding is applied based on the priority of the tickets. For each user, tickets assigned to him in other projects are displayed in a separate row to quickly find out free time for the user across projects.

Currently “Gantt Chart View” is ‘read only’ view. In the next release we will add ‘drag and drop’ functionality for scheduling. 

Question: I already have tickets in my existing project. Why are they not displayed in the Gantt Chart View?

Answer: To enable Gantt chart, we have added ‘Start Date’ on Ticket. After this enhancement on tickets, older project will still not have a ‘Start Date’.  That is why they will not show up on the Gantt Chart. You will need to edit older tickets and assign a ‘Start Date’ explicitly to see them in the Gantt Chart.

Risk Management in Agile Projects

February 13, 2013 By Mridula Velagapudi

5 Comments

Risk management is one of the nine knowledge areas of project management. According to PMBoK, Risk Management has a typical process flow starting from risk management planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk monitoring and control. This process flow has clear objectives of decreasing the probability and impact of events that could delay project delivery, and/or create a budget overdue.

Figure 1: Risk Management Process Flow

This is tailored made for traditional software development models (such as Waterfall model). But it wouldn’t sit very well for Agile SDLC if you tried to fit it in “as is”. Let us see why.

Agile methodologies are based on the premise that software development cannot be compared to manufacturing (from where the traditional project management is derived). Agile works on the concept that software development’s configuration is different and therefore, project management and its knowledge areas, such as Risk Management, too are different and should have different process flows.

For example, every software project is “unique” and not “repeatable” to be produced several times. The following table lists a few differences between configuration of software projects and manufacturing:

Manufacturing Projects Software Development Projects
Repeatable Unique
Well-defined requirement Evolving, with sketchy initial requirements
Production dependent on machine and tools Development dependent on people; people are required to hard code the development; communication, individual knowledge and experience can bring about a significant difference in output. 

Table 1: Configuration Difference between Manufacturing and Software Development Projects

Agile believes that people communicate better face to face than with written documentation, and therefore stresses more on “people” part of it than on documentation. (Now, that does not mean that there is absolutely no documentation in Agile SDLC). Moreover, Agile believes in responding to change over following a plan and therefore, has a process flow that develops, tests and delivers a project in fragments.

The ideology of accommodating change requirements even at later stages of development causes Agile to rethink risks from different dimensions.

In traditional project management, the resources are spent in risk management planning process flow (refer to Figure 1 above), inferred from the visible variation between any two projects. Most of the unknown “Black Swans” are not accounted for, which may occur due to changing project requirements needed by the stakeholders.

But Risk Management in Agile projects takes a different twist when compared to how it is dealt with in traditional project management. That does not mean that Agile methodologies suggest that you just throw off the bowlines and sail away!

Agile insists on designing and coding first, and deal with risks as they emerge. When the project is delivered in small functionalities, the risks emerge as the development progresses. Often the team members identify the risks and the team as a whole discusses how to deal with it.

It leaves the team with the choice to identify the risky parts first and go for its development first. For example the risk could be in terms of judging the complexity of developing a functionality and to experiment with the estimated development velocity vis-a-vis the complexity.

So, you see there is a risk management plan that goes with Agile but its nature is different. As some experts would call it, it is more “reactive” than “deliberate”.

What is your take?

(Photo credit: www.Office.com)

Some New Features : User Contribution, Delayed Tickets Filters, etc.

February 06, 2013 By Nitin Bhide

Leave a comment

Last weekend we added some new and useful features as requested by our users. Here’s the list:

  1. User Contribution
  2. Filters for Delayed/Overdue Tickets
  3. Add Time Log on Past Dates

Check out the new features and keep sending your suggestions. Just click on the ‘green help’ button or email us at Support@bootstraptoday.com).

Feature : User Contribution

By Nitin Bhide

1 Comment

Many times you want to know ‘what is my contribution’ to project. How many bugs did I fix, how many wiki pages did I edit, and how many code commits did I complete?  BootStrapToday now has a useful feature to track each user’s contribution to a project. Just follow these easy steps:

  1. Go to ‘Project Menu’ on the navigation bar and select a project.
  2. Go to ‘Users‘.
  3. Select a user.

The user details page in the right pane will display two sections – “Current Assignments” and “Contributions“.

Current assignments section shows the user’s current role in the project, component ownerships assigned to him and tickets assigned to him.


Contributions section shows the user’s contribution to the project – how many tickets he/she created, resolved and closed, how many revisions he/she committed, and how many wiki pages he/she created and edited.

Feature : Filter for Delayed/Overdue Tickets

By Nitin Bhide

2 Comments

Many users have asked us a question – how do I find out which tickets are overdue, and which tickets have taken more time than estimated? As an answer to this question, we have added some new filters that will act as a quick solution to this problem.

1. Go to ‘Ticket’ in the project menu.
2. Click on the ‘Filter’ icon. A ‘Filter’ dialog will pop up.

3. Now go to ‘Extra Filters” (shown in blue rectangle in above image).

 

4. You will see some drop down filters. Select the appropriate filter. For example, if you select ‘Estimated Time < Consumed Time‘ AND “Due Date < Today”, then you will find tickets where user has spent more time than estimated but the user is still within the specified due date. Now if you select “Estimated Time > Consumed Time” AND “Due Date > Today”, then you will find tickets where the time spent is within budgeted time but the ticket is past its due date.

Feature : Add Time Log on Past Dates

By Nitin Bhide

1 Comment

Sometimes a customer tells you to work on something immediately or you think of some new exciting feature and start prototyping it. The next day you realize that there is no ticket for the work. Hence you add a ticket. However you cannot add the time spent the previous day on that ticket because there was a restriction that you cannot add time for past dates. Also you could log time only if the ticket was currently assigned to you.

Since many users have encountered this problem, some time or the other, therefore we have modified the time logging functionality to allow adding time log for the past dates also. So, here is what it will allow you to do:

1. You can now log time if a ticket was assigned to you now or in the past or you if you are a participant of that ticket.

2. You can select the date on which you want to add the ticket. If a time log of the same date and user exists, then the new one is added to the existing time log. Otherwise a new time log entry is created.

To log the time on a specific ticket,

1. Go to the ‘Ticket’ (from my tickets, project-> tickets etc.)

2. Go to ‘Timelog’ tab

3. Click on ‘Add Time’. A time logging dialog box like the one below will appear.

4. You can now select the date in the date field (marked in blue rectangle).

5. You can also log time in different formats. For example, to log 1 hour 20 minutes, you can use “1:20″, “1h20m”, “80m” etc.

How to Ensure Success as a SaaS Vendor in 5 Easy Steps

February 05, 2013 By Mridula Velagapudi

Leave a comment

Cloud computing has changed the way businesses of all sizes use IT services, notably enough to be branded as a “disruptive technology”. Out of many models of cloud computing, SaaS is the one which has brought out the paradigm shift in the way application software is used in companies. Growth of SaaS over the years has made one thing very clear – SaaS has gained enough trust so as to become a de facto model for software deployment across SMBs and enterprises.

The success of SaaS means a definite end in the usual way of doing business in the application software market. The whole ball game of selling software as a product has shifted to selling software as a service. Therefore, it is quite apparent that only when the services are used or adopted by the customers, will the vendors generate revenue.

Since SaaS is a paradigm shift in the world of software applications, and is largely dependent upon its adoption, surely it must have had (and still has) challenges that needed to be overcome, in order to generate revenue stream in millions of dollars.

If you are considering starting up a SaaS entity, or shifting towards providing your software solution the SaaS way, then you will find this article helpful. Here are five easy steps to remember when venturing out for a SaaS business:

1. Robust multi-tenancy – The Soul…

This characteristic, I would say, is the soul of a SaaS model. To be a successful SaaS vendor, you have to ensure that your SaaS solution is able to handle many customers at once. You have to understand the technicality for ensuring that every instance of your SaaS solution must be able to isolate customers efficiently and allow them to have their unique experiences. This should happen despite your customers sharing the instances and other underlying resources with other customers. The efficiency of seamless scalability is a must before you are ready to go to the market on a wider scale.

2. Sophisticated architecture – The Heart…

If you are building your SaaS solution you are most probably going to use the services of an IaaS provider, such as Amazon EC2 or Rackspace. The heart of an efficient SaaS solution would be its architecture which is able to utilize the flexible infrastructure resources that your IaaS vendor will provide you with. If your SaaS solution is not able to utilize the resources of an IaaS that enables your SaaS solution to provide seamless scalability to your customers, then you may not be able to provide a sustainable SaaS experience to your customers.

Do not underestimate this part, as this will directly dampen the trust factor; and you may want to clearly avoid this situation for a continued growth of your SaaS business.

3. Customer management – The Lifeblood…

Be a forward thinking person. Spend as much time as possible in thinking what features and services will make your customers happy. It is not necessary that you launch your SaaS application with all the features, but it is important that you plan out ahead the features that you will gradually introduce, since it will be easy to incorporate such specifics in your SaaS solution’s architecture.

Along with the feature evolution, you should also plan out well for providing excellent customer support. It’s prudent to understand that if customers are not happy, then the word of mouth may hinder adoption; and if customers do not adopt your SaaS solution, then your business will starve slowly and die.

4. Get your selling pitch right – The Workout …

Right from the infancy of your SaaS solution, make sure you practice the right selling pitch. Remember, the whole ball game of selling software as a product has shifted to selling software as a service. And when you sell software as a service you need to be prepared for providing customer support, flawless upgrades, data backups, data management, and software maintenance, just to name a few of the things.

Building the perception right at the beginning will help percolate the culture of a “service” provider across your business, and help your employees – right from the sales team to the customer support team – to view the customers in different light altogether. Providing a “service provider” outlook will ensure that every employee understands that each new customer sale is about building up a lifelong relationship, and that they are responsible for nurturing that relationship.

5. Test your pricing model around a small target group – The Allergy Test…

Trying anything new means you test its impact first on a smaller scale. When you are ready to roll out your SaaS solution, it will be a good measure to test out the pricing with a small target group. That’s a very good way of judging if the pricing plans that you have are a bottleneck or not for a wider adoption of your solution. And never forget to give free trial options. If you believe in your product, then be confident. Let the customers try for free, gain confidence and come back to pay for it!

A careful planning – both at the technical level and at the customer management level – will make you successful as a SaaS vendor.

(Photo credit: http://www.office.com)

 

5 Ways to Improve Your Communication in Projects

February 01, 2013 By Mridula Velagapudi

Leave a comment

According to George Bernard Shaw, “The single biggest problem in communication is the illusion that it has taken place.”

In reality we fail to realize that we all are different in the way we perceive things and use that understanding as a guide to our communication with others. Probabilistically speaking, there can be as many perceptions about a subject as the number of people present in a group discussing it. Therefore, assuming that you have explained your point of view, may not necessarily mean that it has been absorbed in the manner as you think, simply because the person you are speaking with may process the information exchanged based on his/her understanding of things.

Project management as a discipline requires exemplary leadership skills, and what is leadership without effective communication?

According to Brian Tracy, motivational speaker and author, “Communication is a skill that you can learn. It’s like riding a bicycle or typing. If you’re willing to work at it, you can rapidly improve the quality of very part of your life.” So if you think that are facing communication issues within your project, or if you’ve had a 360-degree performance review which highlights communication skills with a red flag, then here are five ways which you can practice to improve upon your communication in projects:

1. Build a sense of humor:

Sense of humor helps to break the ice. Imagine a situation when you are taking over a new team or implementing a transformation which has been strategically decided by the management. Naturally, you will receive a few cold-shoulders. But cracking a joke when appropriate or laughing at yourself, helps to break the ice and connect with others.

2. Put yourself in the other’s shoe and try to empathize:

If you find that you are unable to put your point across to a team member, then try to put yourself in his/her shoe, and understand where he/she is coming from. Try to re-phrase your statements and opinions according to the other person’s frame of mind.

3. Ask questions and encourage others to do the same:

Sometimes two people may be meaning same but putting it differently, which may either sound confusing to one person or raise a few doubts. This situation may unnecessarily waste everyone else’s time and could be very frustrating. Therefore, it is best to ask questions to clarify your doubts and encourage team members to do the same. Asking questions brings out multidimensional perspective of any issue and helps to present a clear picture.

4. Be open-minded:

Often your team member might have a better solution to a problem. Always keep an open mind so as to listen properly to a team member’s suggestion. You may or may not accept the solution due to constraints such as compliance issue or budget issue. Rejecting your team member’s suggestion without evaluating the pros or cons, or without explaining him/her about the constraints why his/her solution cannot be accepted, may seem very condescending to your team member.  Such a behavior will kill the spirit of collaboration and widen the communication gap between you and your team members. This situation should (at best) be avoided in your project.

5. Summarize:

Always try to communicate in as few words as possible. Simple and clear sentences are understood faster and leave lesser scope for multiple interpretations. Try to avoid jargons and abbreviations unless they are very specific to your project and industry. At the end of a meeting always summarize in clear points what has been discussed. The same should be documented and shared with the project team so that everyone is on the same page.

Do you think there are more tips which can improve communication in projects? Please share with us.

(Photo credit: http://skillhike.co.in/2011/06/communication-skills-story/)

How to Keep Agile Projects on Track

January 29, 2013 By Mridula Velagapudi

1 Comment

Agile SDLC is quite frequently used and it would be fine to call it as ‘mainstream’ methodology. But that is just for the Software Development Life Cycle (SDLC) part, which gives you the process and frameworks for creating a software application. The methodology still has to be managed.

When it comes to Agile project management, there are certain typical project management issues which crop up during the Agile SDLC too. One of the issues is tracking the project.

How do you ensure that your Agile project is on track? Here are a few tips:

1. Let us take the technical approach first.

There is a metric called “Burndown Charts” (figure 1). It is a very good and a simple metric to track your agile project against a given period of time. The fundamental of a Burndown chart is that it helps you plot a graph that displays remaining effort (in terms of hours or points) for a given period of time. Based on the period of time in question, the Burndown charts could be a “Daily Burndown Chart” or a “Release Burndown Chart” or a “Project Burndown Chart”.

 

Burndown Chart

Figure 1: Burndown Chart. Adapted from “Burn down chart”, Wikipedia (2012).

Based on your Agile Work Breakdown Structure (WBS), you would have developed user stories around any particular user functionality and would have a subsequent development schedule and a release plan. Whether it is about tracking a project release plan or one sprint or the entire project, you can track an Agile project by plotting subsequent story points on Y-axis vs. iterations on X-axis. This will clearly show you if you are on track or not. For e.g., you can draw a target line for a weekly sprint based on the estimated number of hours required for various tasks. Then every day you can plot your actual line against the actual work completed. If your actual line is below the target line, then you are on schedule. But if your actual line is above the target line, then you are off track.

2. Now let us get on with the non-technical approach required, which tackles Agile project management from the subjective angle to keep projects on track.

Here comes the ‘unstructured’ role of a Scrum Master. A Scrum Master acts more like a facilitator or a coach, and in many ways is different from a traditional project manager. The key is to understand that a Scrum Master has to ensure that she is able to remove all the impediments that threaten to reduce developers’ productivity and obstruct them from achieving a sprint goal.

Now this has an endless scope and cannot be defined or curtailed in a few bullet points. For e.g., a Scrum Master may have to ensure that the working conditions for the team are right, even if that means controlling the ventilation of the room or ensuring that proper chairs are provided to reduce rapid fatigue.

A Scrum Master’s role is to do a continuous multidimensional analysis of the project – objectively and subjectively – so that she can support the Product Owner in maintaining backlog, release plans and radiating Scrum artifacts such as product backlog, sprint backlog or the sprint Burndown chart.

In short, an effective Scrum Master is also a necessary pedal to keep an Agile project on track.

What is your take?