5 Easy Steps to Project Management with BYOD

Leave a comment

According to a press release by Gartner, the rise of bring your own device (BYOD) programs is the single most radical shift in the economics of client computing for business since PCs invaded the workplace.

Actually, BYOD started when, in 2009, Intel initially recognized a growing trend among its employees to bring their own device to work, and connect it to the corporate network. Ever since, it has seen an increasing adoption by companies. Many companies have adopted it as an alternate strategy to allow employees to use their personally owned devices to work with enterprise applications and access data.

Now that SaaS has crossed the chasm and is not an “alternative”, BYOD can bring real benefits, such as reduced spending by the companies on buying devices and upgrading them, lesser procurement headaches, and faster turnaround for using the latest technology.

But, BYOD came with many strings attached. Some typical areas of concern which threw up challenges were:

  1. Data breach and security
  2. Management policies
  3. Reimbursement policies
  4. List of types of devices allowed
  5. Technology support

If you are considering introducing BYOD in your projects, then all the above factors have to fall in place for you to be able to implement BYOD effectively. Here are five steps which will make your project management easier with BYOD:

1. Draft BYOD policies for your project:

Draft BYOD policies for your own project vis-à-vis the company’s BYOD policies. Over and above company’s legal and security policies, this could include:

  • A list of possible devices that are permitted under the BYOD scheme and your project’s specific technical needs.
  • The “necessary and sufficient” conditions under which upgrading technology is permitted.
  • Expense reimbursement policies for employee-owned devices that are used under BYOD.
  • Approval process for upgrading and maintenance of the devices.
  • Project data ownership guidelines.

2. Declare data ownership:

Every project generates critical data which has its own data security and ownership policies set as per customers’ requirements. It will be better if the project manager separately declares data access and ownership policies in lines with his/her own company as well as those set by the project stakeholders. If you are initiating the BYOD approach for the first time it will help to conduct an orientation session with the team and continuously monitor the same.

The project manager should also coordinate with the support staff to understand the possible controls that can be set up on the devices in order to successfully implement restrictive data access and ownership policies.

3. Choose a SaaS project management tool:

With most of the application software available as SaaS, BYOD has become a reigning reality. Since employees get to choose their devices, they truly enjoy working on their devices. Such conduct makes a good case for using project management solutions that are SaaS-based, with features for collaborative teamwork even under distributed team set-ups. BootStrapToday provides you with all this and more. Check it out for FREE.

4. Factor in an MDM 2.0 Solution

To ensure that the BYOD approach in your project is a hit, make sure that your company already has budgeted for an MDM 2.0 solution. If not, then before you implement the BYOD in your project, get approvals for the IT support to have an MDM 2.0 solution.

An MDM 2.0 solution provides centralized visibility to the devices and users that connect to the corporate network, and allows the IT support to manage the devices by applying the corporate security policies. It also focusses on data creation and update, and remotely lock and wipe a device, which helps to protect the data stored on the device when it is lost or stolen.

With such a solution, you can coordinate with the support staff to ensure your project specific needs are implemented provided of course that they comply with the corporate security policies.

5. Track your BYOD compliance:

It is important that you keep a track of performance under the new BYOD approach for your project. You should develop your own checklist of the factors against which project management under BYOD needs to be judged. For example, with the help of IT support, you can get the right set of reports to understand your team’s compliance with the laid security policies. You could also track device performance. You have to ensure that it does not affect the developer productivity.

How do you think project management with BYOD can be improved?

(Photo credit: http://techsource.datacom.com.au/TechKnowledge/?Tag=BYOD)

Feature Announcement – Gantt Chart Report Released

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

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.

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

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

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

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

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

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/)