How To Avoid That Heavy Feeling With Weighted Tasks in Assign It To Me

Steven NgProductivity, Project ManagementLeave a Comment

Not All Tasks are Created Equal

Let’s say you’re running a small project with 10 tasks, with each task requiring 1 hour of effort by a team member who charges $100/hour. As your project progresses, each task completed represents 10% of your project’s completion.

At first glance, that makes sense. All of your tasks have the same amount of effort and dollar value, so why not? The catch is that each task might have a different value with respect to the actual progress of your project. What if 8 of your tasks are coding, and 2 of your tasks are meetings? Do those two meetings truly represent 20% of forward progress on your projects? Probably not. They probably don’t represent 0% of forward progress either.

Many other project management tools treat all tasks as somewhat equal outside of their effort. When we were creating Assign It To Me, we were trying to provide project owners with some flexibility in terms of deciding how much progress a task can contribute to the overall progress of their project.

The last thing a project owner needs is to get a heavy feeling because they’re not comfortable with the degree of accuracy of their project’s calculated percent complete.

Let Assign It To Me Do The Heavy Lifting

Our solution to addressing the variability of a task’s contribution to the overall project percent complete had to be relatively simple and straightforward in order to balance usability and simplicity.

The mathematical solution was relatively simple— all we needed to do was make the project’s percent complete a weighted average of all of the percent complete of all the project’s tasks. While it would be more powerful for project owners to be able to set anyvalue for a task’s weight by themselves, having to manage such variable values on a large project would be a nightmare.

We basically decided to keep it simple. We have a 6 point scale from 0 to 5 to let you put a relative weight on a task:

  • 0 – Unimportant – This task represents 0% of the project’s overall progress
  • 1 – Much Less Than Normal – This task contributes much less to a project’s overall progress than a normal task
  • 2 – Less Than Normal – This task contributes less to a project’s overall progress than a normal task
  • 3 – Normal – This task contributes a normal amount to a project’s overall progress
  • 4 – More Than Normal – This task contributes more to a project’s overall progress than a normal task
  • 5 – Much More Than Normal – This task contributes much more to a project’s overall progress than a normal task

By default, all tasks in Assign It To Me start with a weight of 3. This way, project owners who don’t want or care about task weight can have equally weighted tasks. In terms of the math, when we calculate the project’s weighted average, we use this formula:

∑(task percent complete × task weight) ⁄ ∑(all task weights)

We use the same 0 to 5 scale for task weight in the calculation. So a 0 weighted task that is 100% complete represents a 0% contribution to the overall project’s progress. A completed task weighted at 5 represents a (5 x 100%) / ∑(all task weights) contribution to the overall project’s progress.

A Note On Folders

Note that folders do not have a user-defined weight. From a project perspective, folders are simply containers for tasks. They have no bearing on any aggregation calculations made by Assign It To Me.

In a task list view, folders will show a calculated percent complete that is the weighted average of all of its tasks, including those in subfolders. Folders do not impact the calculation of the project’s weighted average.

Weight In Practice

So how can you apply this in a real world project? Here are some ideas:

  • You can create milestones like sign offs in your project by creating 0 weighted tasks
  • You can reduce the progress contributed by meetings by setting them to 1 (Much Less Than Normal)
  • You can make some simpler but more critical tasks very important by setting them to 5 (Much More Than Normal)

Also, while our labels for the weight values are sensible defaults, remember that they are still 0 to 5 weightings mathematically. A power user can always choose to ignore our text labels make the numbers mean something else for you. For example, if you make a weight of 2 mean “normal” with respect to your particular project, a task with a weight of 5 will make a much larger contribution to your project’s percent complete.

Remember, we are defaulting every task to 3, so you don’t have to use weighting if you don’t want to. We do, however, hope you take advantage of this feature in Assign It To Me, because it’s a pretty unique and powerful feature.

Wheels, Mousetraps and Other Clichés

Steven NgProject Management, SoftwareLeave a Comment

It’s A Matter of Perspective

In just about every possible discipline, “reinventing the wheel” is considered a wasteful use of time and effort. To coin another cliché, what you really want to do is “build a better mouse trap”. The problem, however, is that those two clichés describe the same activity. A lot of people who are criticized for reinventing the wheel are could just as easily be complimented for building a better mouse trap.

When we built Assign It To Me, we knew there were tons of other successful, well-made project management tools out there. Vince and I had a particular way of doing things, and none of the tools we tried were really optimized for that. For the longest time, we used a bug tracking tool (Fogbugz, in case you’re wondering) for managing billable project work. We still use Fogbugz today, but we actually use it for what it’s designed for— tracking bugs in Assign It To Me.

In the end, we wanted a project management tool that we would love using every day and prevent our projects from losing money. From one perspective, you could say “that wheel has been already reinvented many times”. From our perspective, however, we thought that “there has to be a better mousetrap”… one that works the way we do. So we built it.

Horses for Courses

So why don’t we use Assign It To Me for tracking bugs? Assign It To Me can certainly do that, but we like to use the best tool for the job. While we developed Assign It To Me with an opinionated design, we still made it flexible enough to accommodate multiple working styles. Even between the two of us, Vince and I have vastly different work styles in certain circumstances.

I personally use Assign It To Me in ways that don’t match its intended purpose. While Assign It To Me might be best for billing companies, at its core, Assign It To Me is still like many other project management systems. While we regularly add useful features, we do only try to do one thing well— allow billing companies to manage the profitability of their projects. Some of our features support that, and some of our features overlap with other products, like our time tracking.

But I’ll be the first to tell you, there are a lot of one-trick-ponies out there that can do things like time tracking better than us. And that’s OK. We think that we do profitability better than a lot of other project management solutions out there, because that’s where our primary focus is.

One Thing Well

We’re a one-trick-pony too. Our focus is on project profitability. Sure, our pony’s one trick is actually made up of a bunch of smaller tricks. Those smaller tricks aren’t necessarily mind blowing on their own, but put together, Assign It To Me is greater than the sum of its parts.

It’s not our goal to be the best insert feature here out there. There are a gazillion other products, products that do one thing well, that are better than Assign It To Me at insert feature here. Our position on these features is to provide a minimally viable set of functionality so that a company that doesn’t already have a tool doesn’t have to buy or subscribe to one.

If you try to be everything to everybody, you’re only going to end up with a gigantic piece of bloatware. It’s a slippery slope, because users are always going to demand more. Instead of becoming a giant piece of bloatware, we plan on building out an API for Assign It To Me to let our users integrate with other one-trick-ponies who are best at what they do.

Our Better Mousetrap

Assign It To Me is our mousetrap for project profitability. That might change in the future, if our user makeup is not what we expected, but that’s our goal for now. You can still use it if you don’t care about project profitability, because the same things that lead to project profitability lead to successful project completion. And Assign It To Me provides a strong foundation for running successful projects.

We’ve been hard at work improving our mousetrap to accommodate different work styles too. Our latest version now lets you toggle among new project views— a Kanban-like panel view, an Excel-like worksheet view and a beta Microsoft Project-like Gantt view. Check it out, we think you might like these new views.

Not Now, Later.

Vince IarusciSoftwareLeave a Comment

From Idea To Product

A lot of people have great ideas for products. The challenge of turning those products into ideas is that the ideas are usually only half-baked. What is in your head often comes out a lot different in reality. Things don’t flow as well in the real world as they do in your head.

You can start building without a design, but if you’re designing on the fly, you’re going to spend a lot more time building whatever you’re trying to build. Trust me, I know from experience.

Of course, many of us don’t have the luxury of having a user interface designer on hand. So we download a user interface framework like Bootstrap and start building. And then for whatever reason, we find out Bootstrap doesn’t do some particular thing we want, and integrating that becomes a bit of a challenge. So then we throw that away and try some other framework. And all of a sudden, something that seemed straightforward in our head became a lot more work than we originally thought.

MVP 3.0

“In the biz”, we like to refer to building MVPs, or minimal viable products. That is to say, something with the least amount of functionality that would satisfy the requirements for an initial release. If you’re building a free consumer app, that strategy works well. If you descope the idea in your head to a minimal set of functions that can be built quickly, it will work to your benefit.

If, however, you plan to charge a significant amount of money for your product, your MVP needs a bit of polish. Nobody’s going to pay $50 a month for something that barely does anything and looks like crap doing whatever it does.

But in either case, you need to build something before you build everything. You can’t achieve feature completion in version 1.0. In my experience, the best products I’ve used tend to be the 3.0 version. Microsoft Word 3.0 was the pinnacle of the application, in my mind. While some useful features have been added in the two plus decades since 3.0, most of it has been cruft and wiz-bang features that marketing types use to justify a paid upgrade from existing users.

Back to the 1.0 thing. When you’re building a product, you need to figure out what your killer features are, and then decide what the bare minimum for each of those features can be built in a relatively short period of time.

When we started out building Assign It To Me, Vince and I each had our own grand visions of a perfect 1.0 release that had everything under the sun and the kitchen sink. We learned pretty quickly that if that was our release list, we would never, ever release anything.

You can’t get to a 3.0 if you don’t have yourself a 1.0.

Less. Much Less.

So we descoped. We pared down the functionality down to the minimum set of things that would make our application worth using.

  • Project management. Check.
  • Task Level Time Keeping. Check.
  • Project health dashboard. Check.
  • Task Level Collaboration. Check.

There are a few other things that we included, but all of those features had to be in a minimally viable state.

But that’s not all. When you’re building a software-as-a-service (saas) solution, you need the infrastructure to handle subscriptions. Whoa. More scope. Shoot me now. All of a sudden, there’s more to build than just a client app.

  • Web application server. Check.
  • Database. Check.
  • Secure Payment Processing. Check.
  • Multi-tenant architecture. Check.

I think you’re starting to get the picture. It took us a while to get the core infrastructure and base application in place. And we had to say “no” to a lot of features while getting to 1.0 (Vince can attest to all the pushback I’d give him every time he had a good idea for a new feature). The best thing you can do while getting to 1.0 is to push as much as you can into your backlog. Get a solid foundation and make sure you design it to be expandable. But be careful not to overdesign. Just don’t design yourself into a tiny box. Once you get that foundation, adding things gets easier.

Not Now, Later

When we reached 1.0, our application wasn’t the prettiest thing out there, but it was serviceable. It worked, and it did what it needed to do. Making it prettier was easy, because all the hard parts were now in place. Since hitting 1.0, improvements have been coming at a furious pace. If we tried adding some of our latest features to the 1.0 version, we would have never released. Seriously. We’d still be developing.

The path to 1.0 was not smooth at all. We hit roadbumps, got demotivated, made progress and then got re-motivated. This vicious/virtuous cycle is pretty typical, but if you’re looking to make a product, it’s not an insurmountable task. The key is to manage your releases and to be ready to look at some of your less important features and say “Not Now, Later”. Focus on getting something out. If you’re self-bootstrapped, it’s unlikely that you’re going to get an A+ product out on your first try. Pare down your product and aim for a B product instead. It’s much easier turning a B into a B+ and then into an A than it is to start with nothing and end with an A+.

One of Vince’s favorite sayings is “continuous improvement over delayed perfection”. It’s much easier said than done, but if you can find the discipline to adhere to that saying, you’ll get better results faster.

Not Invented Here

Steven NgSoftwareLeave a Comment

Reduce, Reuse, Recycle

When you’re building an application, it makes sense to take advantage of as many open source libraries as you can. These libraries can often save a lot of time… or not.

Fit or Misfit

When you’re building an application, it’s easy to fall into the trap of assuming your Google results for some function you want will actually do what you want. While these libraries can be pretty good at what they do, they tend to come with three common pitfalls.

First — Some libraries are trying to be everything to everyone. The programmer(s) have done a fantastic job of building a complete piece of functionality and have trapped all sorts of edge cases. This isn’t a problem if you’re OK with the library’s out-of-the-box functionality, but if you’re trying to do something very specific, you may quickly find yourself trying to ram a square peg into a round hole.

Second — In a lot of cases, these libraries are black boxes. Documentation can be hit or miss with these libraries. The examples work great, but when you try to write an example tailored to your needs, things get dicey. You don’t know how well the libraries scale with large amounts of data without doing your own testing. In some cases, you also don’t know how secure the code bases are. Sure, you can dig into the code, but the reason why you even considered the library was to save time, effort, and headaches.

Third — Since most libraries are borne from a programmer’s own need, they are developed with themselves in mind. That is to say, there’s an opinionated design. The API or data structures are a certain way, and they may not match the way your application is built. They may also be a mismatch for the other libraries you’re dependent on. Just figuring out the learning curve for remapping your data structures could take longer than if you wrote your own library from scratch.

Not Invented Here

Someone wise once said “If you think something is easy, you probably don’t know what you’re talking about”.

Thinking you can easily build an application by just grabbing a pile of pre-written libraries is a trap. Are you going to add D3.js to your application just so you can put a single pie chart on a single page in your application? That’s a lot of code to be adding just for a small feature.

Unless all of those libraries you wanted were written by similar thinking people (pro tip: they’re not), you’re going to be dealing with a bunch of different programming styles and API invocation approaches. Integrating a pile of code written by a bunch of randos may not be technically difficult, but if you’re trying to do something non-trivial, integrating that code is going to be time-consuming. First you have to learn how each library works, and then you need to make the libraries talk to each other. And then you need to make sure that upgrades to one library doesn’t break anything relying on the other libraries.

In some cases, you’re better off writing your own new code. And you know what, it’s not the end of the world.

Be Selective

Let’s be clear, it makes no sense to re-invent the wheel if you can at all avoid it.

So what should you do? In building Assign It To Me, we’ve gone through a litany of different libraries. When we discuss adding a feature, we always see if any wheels have been already invented and whether they fit on our car, so to speak. If they don’t we have to make our own wheel.

In general, I find that large libraries that do more than I need tend to be a bad fit. The best libraries are the smaller, “do one thing really well” libraries. They’re easier to decode and integrate. Because we try and ensure that mobile users can use the same set of code, payload and dependencies matter. Or more clearly put, I don’t want to deal with sizable pieces of new code or dependencies on libraries I don’t already use. For example, we don’t use jQuery in any of our client side code. I’m not going to add an extra 100KB or so of code to our client app just so we can do something trivial. Heck, I’m going to need convincing even to do something non-trivial. The cost is that I lose access to hundreds of canned user interface libraries, but it hasn’t been nearly as big as a hindrance as it would seem.

From my perspective, it pays to be hypercritical about including any new libraries in your code. All of your externally sourced libraries move at their own pace. As mentioned earlier, an upgrade to one library can lead to a litany of negative side-effects in your other libraries.

There’s a delicate balance between being able to show forward progress quickly by using some canned code and making sure that the rest of your code base is clean and performant. Do evaluate and consider open source libraries for your applications, but don’t be afraid to write your own code either. Remember — a lot of open web frameworks were written because existing frameworks didn’t do the job that the programmer needed. It doesn’t mean that you need to eventually rewrite all the third party libraries you’re using. But if you outgrow them, it’s better than being dependent on someone else’s work and update schedule.

Enterprise Business Intelligence Can Be Hard

Vince IarusciBusiness Intelligence, KnodeoLeave a Comment

We’ve seen it happen many times. A customer is sitting through a polished demo of some commercial-of-the-shelf product from one of the big Business Intelligence vendors. Screen after screen of dashboards and reports with perfect data flash by. The customer’s first thought is that this is the tool that will improve all business decisions. The salesperson’s goal is to close the sale. In most cases, these customers are walking into a world of hurt.

I’m not saying that big BI vendors are evil, they just have their place. Steven and I have sold and installed commercial-off-the-shelf software to many companies and these BI tools are used every day by our clients. We’ve found that these BI stacks often work well in larger companies with big IT budgets and resources but implementing enterprise BI can be hard for most small to midsize companies. In many cases, it’s like trying to “crack a peanut with a sledgehammer”.

Let’s take a look at the BI pains experienced by different users in an organization.

Business Intelligence Pains for C-Level Executives

  1. High Costs – Current BI vendors make money selling software which is feature rich and over-engineered. These big enterprise business intelligence vendors make their money selling you solutions with features you don’t need. Furthermore, licensing fees are often complex and have annual maintenance costs as well.
  2. Esoteric Skill Sets – Content development requires specialized skills and these skilled-up developers often move to greener pastures. The market for talent in any given enterprise BI product is limited to the people who have had access to them which creates an artificial scarcity that drives up prices. In addition, market value increases as your people get “skilled up”.  This can lead to increased turnover and high replacement costs.
  3. Shelfware & Adoption of technology – Most BI vendors have many embedded tools. These features and options show well during the sales cycle but are often not used after implementation. In order to satisfy a broad set of the buyer’s checklist, many business intelligence vendors focus on feature abundance over feature excellence. After implementation, most solutions use only 20% of a product’s tools, in spite of paying for 100% of a product.

Business Intelligence Pains for Users

  1. Inconsistent information – A common mistake is that users rely on the front end BI tools to define the business rules instead of a common information database.
  2. Multiple Versions of the Truth – In spite of the “Single Version of the Truth” benefit of business intelligence solutions, the reality is that it is difficult to achieve. Part of the problem lies with the fact that there is a lot of leeway in how a solution is implemented. Improperly implemented solutions scatter multiple versions of the same business logic across multiple layers of the solution. This eliminates the possibility of achieving that “Single Version of the Truth”.
  3. Learn new complex tools – Users just want the information they need in the tools they already use but users are often forced to navigate & learn complex software.  Enterprise software is known for being user-unfriendly. Part of the problem is that the designers and developers rarely use the software themselves. Forcing users to navigate and learn complex software costs your company money. Having to learn new technology can also increase the stress level of your team members.Enterprise Business Intelligence Tools
  4. Forced to use standard tools – Different users have different information needs. Out of the box query, reporting, analytics, and dashboard tools restrict the user’s delivery options.
  5. Limited Functionality – Different users have different information needs. Out of the box functionality of enterprise business intelligence tools can make or break your company’s implementation.Users are often beholden to the release schedules and feature prioritization of their enterprise software vendors when looking for new features.

Business Intelligence Pains for Developers

  1. Specialized knowledge required – IT managers and developers don’t want one more complex tool to manage.
  2. One More Tool – Most IT departments are already busy and adding one more tool to the mix simply adds more complexity and work. Enterprise solutions build on the same underlying principles of moving data and querying databases. They have their own way of doing things and ultimately that leads to increased training, development and maintenance costs.
  3. Constraints on development – Customizing packaged software can be like “stuffing a square block in a round hole”. Developers can’t customize solutions when the proprietary software is “locked down”.
  4. Software administration is hard – BI vendors make money with version support changes and licensing. Upgrading and migrating content between versions can be difficult and time-consuming.

Pain relief with Knodeo

Relief for C-Level Executives

  1. Reduced Costs – Knodeo software costs are $0. Knodeo base components build on open source software and have no software costs.
  2. Commodity skill sets – Many of the technologies used already exist within most companies. Using common technology makes it easier for the business to find the needed skill sets.
  3. Adapts to your business – Many of today’s technologies used are open and extensible. Businesses change daily and Knodeo’s tools adapt to your business without the constraints of proprietary software.

Relief for Users

  1. Trusted Information – A common information backbone contains all the business definitions. The centralized analytics database defines the business definitions instead of the individual BI tools.
  2. Use established familiar tools – Users are already familiar with tools like MS Excel for reporting or MS Access for queries. Knodeo can integrate with any existing BI tool.
  3. Customized reporting – Create customized reports, analytics, and dashboards in the open Knodeo Launchpad. Develop apps to help with your business processes.

Relief for Developers

  1. Unlimited toolsets to support business needs –  Developers have options to select the toolsets that fit best for the required business case.
  2. Open Extensible architecture – Open architecture gives developers the freedom to implement solutions based on the user requirements and not the constraints of proprietary software.
  3. Automated systems – Tasks like installations, upgrades, data loads and report delivery execute using the open Knodeo automation tools.