New Inline Quickedit feature

Here at PMRobot, we're always looking for ways to reduce the number of clicks.

We call our latest improvement the "Inline Quickedit".

To use the Inline Quickedit feature, simply click or tap a field in the List view:


You’ll be presented with a touch-friendly pop-up to quickly select the field:


Two clicks and you’re done!

This feature currently works with:

• Ticket Type
• Priority
• Effort
• Milestone
• Assignee

Even easier...

After carefully listening to our users' feedback, we've launched an update of PMRobot that's even easier to use.

So what's new?

1. Project selector with search

Now you can find your projects quickly with typeahead search:

It's placed prominently at the top left in a large font, for easy access.

2. All your settings in one place

You said: "I can't find my settings!"

We listened :-)

No more hunting around. They're all organized in one place now. Just click More... Settings.

3. Hide unwanted features:

You said: "My screen is cluttered with things I don't use!"

We listened.

Too much clutter? Clean it up by turning off the features you don't use!

Organization primaries can change this at https://pmrobot.com/organization/info

4. Feedback and Knowledge Base

Have some more ideas for us? Not sure how to do something?

Check out our need feedback and knowledge base at:
http://feedback.pmrobot.com

Waterloo Region Infographic

This week we have another great infographic. This time about PMRobot's hometown -- Waterloo, Ontario, Canada.

Sortable has put together some great stats about the region:

You can click the graphic for the original article at Sortable.

Perils Of Multitasking infographic

As a follow-up to my productivity post entitled "Multitasking is toxic", Peter Kim emailed me a great infographic with some stats about how bad multitasking really is for you.

Have a look:

The original can be found here.

New: Clean and simple navigation

PMRobot has a great new menu and navigation system!

We've always had the most features, but sometimes it's been a bit difficult to actually find them. :)

Those days are over.

Everything is now right at your fingertips.

We've crunched through over a year of logs and statistics to determine the most frequently used pages, and put them right up front.

The less popular (but equally useful) pages have been moved to a secondary menu.

They're still easy to access, but don't get in the way of your day-to-day work.

We've also improved the "quick submit" box by moving it to the left and sprucing it up:

...and don't forget -- PMRobot works great on mobile devices like smartphones and tablets!

We hope these improvements help save you even more time, and make your day just a bit more pleasant :)

We're continuing to work hard every day to make PMRobot faster and easier for you.

What do you think of the new navigation?

Take a vacation from project management!

Project management is great fun, but sometimes you need a break!

You might start packing up your laptop and smartphone to continue working the entire time.

Or...

Perhaps you'd like a real vacation?

In that case, you probably need to assign a point of contact to help your project run smoothly while you're away.

So how can PMRobot help with this?

We've built in a number of features to assign a "helper" to interface with your team members and clients while you're away.

All recent activity is listed in the Newsfeed, making it easy to see, at a glance, what needs attention.

The Member Overview feature lets you view another member's dashboard.

Meanwhile, you can use Redirect Clarification to redirect questions posed to people that are away.

Read the full details in our new tutorial entitled "Going on vacation."

Drag and Drop Sorting + Gantt Charts

This week we introduced two great new features!

Now you can spend less time managing and more time getting things done.

Drag and Drop Sorting

Instead of dealing with the abstract notions of high, normal, and low, we now use the Agile concepts of Current, Backlog, and Icebox to give an indication of the order in which groups of tickets will be worked on.

Within these main priority levels, you can simply drag tickets up and down to fine-tune the exact ordering of individual tickets.

Try it now at: https://pmrobot.com/tickets/sort

Gantt Chart

This week we also introduced a new beta feature: the Gantt Chart.

A Gantt Chart gives you a quick, visible overview of upcoming milestones and resource allocations.

You can also see at a glance which tickets have not yet been assigned.

Give it a try right now at: https://pmrobot.com/chart/gantt

Don't forget...

PMRobot keeps everything in one place, making your job easier.

No more information scattered across 7 different tools.

With PMRobot, there's only one tool to learn, and one place to search for all your files, tasks, and project information.

Questions or ideas? Contact us at https://pmrobot.com/help

---

About the author: Jason Hanley slaves tirelessly, spending his days and nights devising new ways to make software project management faster and easier. While PMRobot is managing his projects, he enjoys riding camels in the Sahara desert, teaching English in Spain, and exploring the south of France.

How to: Manage Remote Projects

Managing a remote project is hard work!

Before starting Syllogistic Software, I worked for a large software corporation, and managed several remote teams. It was always a challenge to:

1. Stay on top of remote workers' task status
2. Communicate questions and answers
3. Help the remote workers keep up with everything else happening in the project

So what tools did I employ to help the situation?

1. Email
2. Conference calls
3. Microsoft Project

When I started my own software consulting company, I tried using these same tools, but found a few problems:

Problem 1: People don't answer email

Even back then, people were buried in email. They choose the easiest ones to answer and ignored the rest.

If you asked them a complicated question about the next steps of a project, it sat in their inbox for days, gradually pushed down the list by other incoming emails.

Problem 2: People forget what is said in meetings

To solve problem 1, I would often call or schedule a meeting. During the meeting, we would go over the questions, determine action items, and record them in meeting minutes.

Unfortunately, some of these actions items would sometimes still fall through the cracks, and not make it to a remote worker's todo list.

Problem 3: Microsoft Project only works for initial high-level planning

MS Project is a great tool for coming up with a "grand" plan before starting a project. But the pretty Gantt chart you create is only valid for a day or two before -- you guessed it -- something changes.

Then you have to go back and re-adjust everything, and your beautiful chart starts looking messy. A week later, there are 5 new scope items, and you're already well behind the planned schedule. Your project plan has essentially fallen to pieces, because you've been so busy putting out fires that you haven't had time to keep it current.

So how do we solve these problems?

After many years of iterating through various fixes, I came up with several techniques that worked:

Solution 1: Clarification questions

The very first version of PMRobot came with a feature called "Ask a clarification question." This remains one of the most important innovations.

When you ask someone a question, it tracks its status, and helps remind the person who has been asked the question. This way, they don't delay the entire project by forgetting to answer.

Solution 2: Track work items in one place

Instead of requiring people to keep track of everything they need to do on their own, create a central work repository that's easy to keep up-to-date.

PMRobot provides a dashboard for workers that shows them exactly what needs to be done, in the exact order they need to do it. After a quick glance, they know their next step.

In addition, if they ask a question about a particular feature, the answer isn't lost in some document called "Week 5 Meeting Minutes." The answer to their question is in the exact same place as all of the other work details.

Solution 3: Use a dynamic project management tool

Microsoft Project is great for static, high-level, upfront planning. If you need a rough overview of the "grand plan," it can help.

Once the project starts, however, you need a dynamic tool that makes it easy to add and update new information.

A major part of project management is change management. Clients change their minds, technology fails, people get sick, and generally -- things change.

Your project management tool needs to be built with change in mind.

PMRobot is built with change management at its core. Every feature helps you control the chaos, and manage each change one by one, getting you closer to meeting your project goals.

Summary

As you can see, many of the features built into PMRobot have been designed to solve very specific problems -- problems that are very common to software consulting.

If you're struggling to keep up with emails and conference calls, consider trying a new approach, and see how these techniques can help tame your chaotic project.

---

About the author: Jason Hanley loves bringing order to chaos. He travels around the world, manages a team of remote developers, and is constantly iterating and improving PMRobot.com.

- Jason Hanley

Removing the Mailman

When I started working at Syllogistic Software, all client communication went through my manager. They knew him, he knew them, and it was simpler that way. This worked great for about 30% of the emails we sent because they were managerial questions, like getting estimates, talking about features, and scheduling work. Once all that was done, it fell to the developers to actually do the work, and interpret the clients’ requests. And sometimes it wasn’t 100% clear what they wanted.

Enter the mailman. I would write up a question about something that we didn’t know, then my manager would look it over and then email it onto the client, usually verbatim. Then the client would respond to my manager, and my manager would forward the information back to me. Much of his "work" consisted of simply passing notes between the two sides. It was ridiculous!

This story was a big driver behind how we designed PMRobot. We wanted to have clients use the system, and communicate directly with developers, so that our manager didn’t have to be a mailman as well. This change also sped up how quickly we communicated with clients, allowing us to get answers within minutes, instead of hours, or even days. Now that our manager is travelling in Europe this is especially important. He’s no longer a bottleneck, and we don’t have to worry that “the answer is in the mail”. :)

---

About the author: Travis is a programmer for Syllogistic Software and helped build and design PMRobot.

Top 3 Worst Ways to Manage a Team

Five years ago, I wrote a short post about the worst possible ways to manage people. These are still popular techniques that managers often fall back to.

So what are these common management traps you should avoid?

#3 - The Ostrich Mentality

People fighting? Project running eight weeks behind schedule? New technical challenges are making success look unfeasible?

No problem! Carry on, business as usual. No need for change. Let's just keep doing things the way we've always done them.

This is what I call the Ostrich Mentality. Just stick your head in the sand and hope everything turns out alright.

What do to instead?

Admit problems frankly, have a discussion, and take action to change things.

Not tomorrow, but today!

#2 - The Ditch Digging Theory

This is when a manager believes that every task in a complex business process is equivalent to simple manual labor.

When a project is running behind schedule, they simply add more people.

This concept works fine -- if you are indeed digging a ditch. If you're doing anything more complicated, it fails miserably.

Adding more people to a project that is already late can actually make it take longer! I discussed the details in my post about keeping your teams small.

What to do instead?

Realize that business and information technology projects are complex beasts, involving specialized knowledge, and lots of communication.

If a project is running late, resist the urge to add more people to speed it up.

Instead, focus on trimming the scope to the bare essentials, and getting a solid deliverable out there. Then, create a follow-up project for the remaining lower priority pieces.

#1 - The Warm Body Theory

This one bothers me personally the most, probably because it is so prevalent and so toxic.

When managers have "warm bodies" (ie. people sitting in an office or meeting room) in their field of view, they equate this to productivity.

Nothing could be further from the truth.

If your employees are physically present at the office 10-12 hours a day, how many of those hours do you think they are mentally present, and actively contributing to the project?

Pulling five people into a two-hour meeting to "discuss the schedule" might burn $1,000-$2,000 of budget, and accomplish next to nothing.

What to do instead?

Make the schedule (the real schedule) and task commitments public and accountable.

Track everything in a live, accurate system that the manager, workers, and clients can access and update in real time.

Embrace flexible working hours and telecommuting. Let people balance their work and life commitments.

Once you've clearly defined what needs to be done, and who is responsible for doing it, you won't need to chase people down every five minutes for a status update!

Summary

To briefly summarize, here are the top 3 management "techniques" to avoid, and how:

• The Ostrich Mentality: Keep your head above the sand and take action!
• The Ditch Digging Theory: Don't add more people to a late project!
• The Warm Body Theory: Track accountability, and let people take responsibility!

---

About the author: Jason M. Hanley has owned a software consulting company for 9 years, and is the founder of PMRobot.

Keeping it all together

When I was a co-op student working for SSI, I would routinely leave for four months, only to return to a new set of tickets and a lot to catch up on. One recurring issue was transferring all that knowledge to someone when I left, or getting it passed back to me when I returned. After all, developers were problem-solving via email, asking managers how to do things, and storing files locally. Before PMRobot, it was all a mess.

Recently I came back to a ticket that had been in development for the past eight months. There was a huge amount of communication for me to look over between the developer, client, and manager. Luckily it was all in one place. I could clearly see the technical discussions alongside the client questions instead of switching between multiple email threads, making it easy to get up to speed.

Now I’m continuing work on this ticket and progress is going smoothly. I can quickly reference technical documentation, and download the related files without having to wait for someone to send me everything. If there are any issues going forward, I can directly contact my manager, fellow developers, or the client all from the same place. With PMRobot, I have the tools to keep it all together.

PMRobot Mobile: Always on the move

Let's face it -- People are always on the move.

You're not always in front of your desktop or laptop.

Suppose you're on the train, heading to work, and want to check in on your notifications and answer a few questions.

Now it's easy!

Just open your mobile web browser and sign in at same place as always -- https://pmrobot.com/home

PMRobot will automatically adjust to your screen size and present you with an optimized mobile experience.

This works on just about any device with a modern browser that supports CSS media queries.

Here are some examples on iOS (iPhone/Apple):

...and a few screenshots running on Android (Samsung/HTC/Google/etc.):

It works best on modern browsers like the ones in iOS and Android, but we'd love to hear how it looks on your device.

Happy trails!

New Feature: Two-step verification

The standard ticket workflow in PMRobot is very simple. For instance, if someone finds a problem:

1. A bug ticket is submitted and assigned
2. The bug is fixed and marked 'resolved'
3. The ticket is returned to the original submitter to be verified

There are cases, however, when you need an extra level of verification.

For instance, if it's a very complicated problem that requires a lot of testing, you may want a member of your Quality Assurance team to check the resolution first.

As of this week's release, PMRobot now supports this workflow in two ways:

1. A project can have a "default verifier" who will be required to verify tickets first, before they are returned to the original submitter
2. Individual tickets can set the "verifier" field to require two-step verification for just that ticket

The new workflow looks like this:

This new workflow is very powerful, but completely optional. If you don't set a verifier, everything will work exactly as it always has.

If you'd like to learn more, check out the full tutorial at:
  http://help.pmrobot.com/2012/tutorials/two-step-verification/

And if you have questions, don't hesitate to contact us here.

Getting Software Projects Into your IT Project Plan and Out the Door

This week we have a special guest post from Jennifer Whitt, PMP:

With the advent of “the Cloud”, most project management software applications have migrated from desktop applications to the Software as a Service (SaaS) model. There is much complexity involved in managing these types of projects. There are scores of people that are involved in the process that touch”virtually nothing” when it comes to something tangible. All the 1’s and 0’s need to be aligned just right! In order to accomplish this people meet incessantly for weeks and many times months at a time.

 
Finally, after all the meetings, late nights, early mornings, and long days the application is ready to go. The new software product is launched and everything comes to a grinding halt! The product release turned into a product escape. The help center queues are backed up for hours, angry customers are emailing in to express their dissatisfaction, and worse yet…they start telling other people about what a crappy product this has turned out to be.

You certainly didn’t account for any of this angst in your IT Project Plan. What went wrong? A whole lot of things. Whenever new code is introduced into a production environment there is always a collective holding of the breath until things begin to settle down. In theory, there is a pre-production environment that should precisely mirror production, but this is not always the case. Configurations may not be right, servers aren’t the same, and other applications may conflict with the new application. This causes hearts to race, tempers flare, and profitability to dissipate.

Fingers start to be pointed as to who is to blame. Is it the Quality Assurance team? Certainly they should have caught all these things in their testing. Is it the Product Configuration team? Maybe the deployed the wrong packages to the wrong environment or the right packages to the wrong environment. Is it the Project Manager? This person is responsible for the entire project, right?

Include Production Release Candidate Activity in Your IT Project Plan

You only have to live through a bad deployment once or twice and you will quickly learn that you want nothing to do with that ever again. You’ll start finding ways to prevent that from happening. You’ll look at your IT Project Plan and see what gaps need to be filled. 

 
The following is a starting point if you have experienced the pain of a bad deployment. There’s no guarantee that this will help things go 100% smoothly, but it will certainly make the process smoother and remove the finger-pointing exercise that occurs at the end.

1. Create a Form – Sure, a form is the solution for everything that ails a project manager. But, there’s something to be said for that. You want to create a Production Release Candidate form that includes the basics about what will be deployed. Include a brief description, the target date of when it will be deployed, what else will be deployed along with it, and room for LOTS of signatures.
2. Talk About It Each Week – Talk about this production release candidate at each of your weekly status or PMO meetings. Start talking about it at least a month out so that people know it’s heading their way. It may be included in the IT Project Plan, but you can’t make assumptions that people will read the plan. IT needs to know it’s coming to make sure the right hardware is in place, QA needs to know it’s coming so they can thoroughly test it, the Documentation team needs to know it’s coming so they can prepare user guides and training manuals. There should not be one person in the company that is surprised that there is a release that will be happening in the next 3-4 weeks.
3. Get Approval from All Who Have a Stake in the Project – The key managers from each department should be on that Production Release Candidate form. Once the application or product is in its finished state, you should go around to each manager and get their written approval. There should be no hesitation in signing this form if they feel everything is ready to go. Don’t settle for a verbal approval. Require that this person sign this piece of paper saying that they have done their due diligence in reviewing it from their department’s perspective and feel comfortable with it being deployed. Requiring their signature will make them look at things much closer and remove their ability to point fingers at other departments later. Who are these key managers? At a minimum you should have Engineering, QA, Client Support (Call Center), Marketing, and Training/Documentation. It will be different for every company, but the principle is that you want to make sure that everyone has had a chance to say their peace and feel comfortable with the deployment moving forward.
4. Get Approval from One Last Person – You should have room on the bottom of the form from the one person these different departmental managers roll up to (depending upon the size of the company). It may be a VP, COO, or President of the company. This informs them what is going on and lets them know that the entire management staff feels comfortable with what is about to be deployed.You are now in a much more comfortable position to release the product or application into a production environment. You’ve accounted for approvals and sign-offs in the IT Project Plan and everyone’s signature is literally on the same page. There’s no guarantee that everything will go 100% right, but you can be assured that things will go much smoother with this high degree of scrutiny.

An Interesting Thought on Who Should Have the Final Say

Most development shops are set up that once QA has signed off then everything should be just fine. They are usually one of the last phases in the IT Project Plan and have one of the toughest jobs. However, I’ve seen some development companies have the final call (if not joint final call with QA) be with the Support Center. This is the group that handles the customer calls and helps them with their issues. In talking to someone who runs a call center, his view was that “every call that comes in is an indictment against the software”. His goal was to mitigate and minimize as many of these calls as possible. This is the group that is on the front lines, hears the angry customers, and is responsible for helping them solve their problems. Unfortunately, these many times take the form of “workarounds” that may or may not ever be fixed the proper way. 

Why not let this person be very involved, if not THE person that makes the call on whether a deployment is ready to be released, or if it’s just about to be another product escape? QA many times gets too sterile and removed from the true functionality of the software. Engineers are too close and can’t see the forest for the trees. A project manager just wants it out the door and the Business Analysts have forgotten about it at this point.

All of the above activity, scrutiny, and approvals take time. That’s why it is so important that you account for these in your IT Project Plan. Otherwise, people will be scrambling at the last minute and no good ever comes from last minute fire-drills.

Where will your software be in 20 years?

When creating software these days, people mostly think 1, 2, maybe 3 years out.

I recently touched based on a job costing program I wrote in C++ when I was 16 (and re-wrote as a client-server app in Java/MySQL) that is still being used on a daily basis.

That's nearly two decades of active service!

And if you think about it, there's still quite a lot of software from that era still kicking around: Windows, Word, Excel, BSD, Linux, Photoshop, and many others.

There's fad software, and there are programs built to adapt, and stand the test of time.

Photoshop today is certainly more advanced than the first version released in 1990, but the core principles remain the same.

Successful software products must constantly evolve to suit an ever-changing environment.

It's easy to get caught up in day-to-day bugs and support requests, but it pays to stand back and take a broader view every so often, thinking about the long term.

So -- Where will your software be in 20 years?

New Video: PMRobot tour

We've updated our product tour video at https://pmrobot.com/tour

The new tour features a fictitious software consulting company working for "Fun Pet Games Inc." to create the new hit app "Angry Hamsters".

We show you how quick and easy it is to:

• Create and assign tickets
• Ask and answer clarification questions
• Log and track time and use automatic timers

Check it out at http://youtu.be/4Oy4-P9ZRF8 or below:

The history of issue tracking systems

Web-based issue tracking systems (often referred to as "bug tracking" systems) have been around for a long time. Let's take a trip down memory lane and review issue tracking software to date.

1998 - Bugzilla

Bugzilla is arguably the great-grandfather of all web-based bug tracking systems. Written in Perl in 1998, and still in active use today, it defined a lot of conventions used by the systems that followed.

A bug in the basic Bugzilla workflow can be in one of the following states:

1. Unconfirmed
2. New
3. Assigned
4. Resolved
5. Reopened
6. Verified
7. Closed

Bugs can transition between these states in a number of standard ways. For example, when a developer completes work on a bug, it moves from Assigned to Resolved. A quality assurance (QA) person then tests and can put the bug into the Verified state if the developer's fix is confirmed.

This workflow has remained largely unchanged over the years.

In addition to bugs, Bugzilla allows "tickets" to track and prioritize feature requests in the same database.

2000 - Mantis Bug Tracker

Started in 2000, but not reaching version 1.0 until 2006, Mantis Bug Tracker (or "MantisBT") is a popular open source bug tracker written in PHP.

It introduced a much nicer user interface than Bugzilla, and offered more customization, including customization of the bug workflow and state transitions.

Although primarily meant for open source projects, Mantis is a very capable system. We used it for several years at Syllogistic Software prior to development of PMRobot.

2003 - JIRA

JIRA, a commercial product launched in 2003 and built in Java, represented another step forward for issue tracking systems, adding additional customization options, and a powerful plugin architecture.

In addition to issue tracking, Atlassian offers a number of products that integrate with JIRA to help with project management, documentation, and source control integration.

The JIRA platform tends to work best for large enterprise software projects.

2006 - Trac and Redmine

In 2006, two similar projects were born: Trac and Redmine. Both are open-source project management and issue tracking systems. Both offer web-based ticketing system similar to Mantis, along with support for milestones, Wiki-style documentation, and source integration.

Trac is written in Python (a language favored by Google), whereas Redmine was developed on the recently popular Ruby on Rails framework.

Both systems have a multitude of functionality, but their user interfaces can be confusing for beginners or non-technical users. They are targeted towards open source projects, or other highly technical teams.

2008 - Pivotal Tracker

Although it focuses more on agile feature tracking than issue tracking, Pivotal Tracker introduced a number of innovative user interface enhancements.

Its extensive use of multi-column drag and drop allows quick reordering of "stories" (similar to tickets). The UI also allows for one-click transitions between states with buttons such as "Finish", "Accept" and "Reject" easily accessible on the main story list.

Using Pivotal requires a through understanding of the Agile Methodology, and is best suited for organizations that have fully adopted it. The software uses many Agile terms in the interface, and assumes that your process mirrors the built-in states.

It is best suited for organizations that have a stable, fixed team working on long-term projects. Otherwise the "story point" estimation methodology, and overall workflow, tends not to work well.

2012 - What's next?

It's been nearly four years since the last major innovation in issue tracking.

We're seeing a lot of action in the mobile world, but mostly iOS and Android applications to access existing issue tracking systems.

What's the next big thing in issue tracking? Let us know in the comments below.