2

From the inventor perspective that has a patent-attorney-team developing a nonprovisional patent application, I am trying to put together a plan comprising a list of deliverables (to be produce by patent attorneys), each with an estimated date. Although I have project management experience, I do not have patent application experience (first attempt at a patent).

Deliverables are workproducts and artifacts produced by stakeholders.

Questions

  • Is there a good list of Non Provisional Patent Application artifacts / deliverables?
  • How can I gauge progress with a looming deadline (April 2019)?

I have found the USPTO Patent Application Checklist, however, I think I should be focused on the claims and how they are progressing between now and the final draft?

4

Always Plan Based on Your Project's Available Resources

I am trying to put together a plan comprising a list of deliverables (to be produce by patent attorneys), each with an estimated date. Although I have project management experience, I do not have patent application experience (first attempt at a patent).

Even if you did have experience with patents, you can't really estimate how long something will take someone else to do. The only tried-and-true way to estimate such work is to ask the task-performer to estimate how long it is likely to take them to complete, given their particular skills, experience, and resources.

As a non-patent example, if you ask me how long a particular task would take me to complete in Ruby, I might tell you a couple of hours. However, my estimate of how long it would take me might be very different from how long it would take you. Even if you're a Ruby programmer and familiar with the problem domain, you might still be more or less experienced than me, have more or fewer things on your calendar that are competing for your time, or have a better or worse toolchain for building a particular widget. My estimate is therefore unlikely to be valid when used to estimate how much work (or time) something would take not-me.

It's also tempting to think that you can just track against the average time that similar tasks on similar projects have taken other people, but then you're still left with the fact that an average is not the range that comprises it. You might see that the average is X months, but a closer look will show you that similar projects are often done between W..Y, and the delta may be quite large. So, other people's numbers may help you guesstimate, but they aren't necessarily very useful as a baseline for your current project.

The best thing to do in such situations is:

  1. Define your ideal budget.
  2. Get the task performers to estimate the time and complexity of the work if they do it. NB: This is the most important step for getting realistic estimates for the current project.
  3. Calculate the range of costs (including optimistic and pessimistic estimates) from the task estimates provided to you.
  4. Take another look at your budget, and decide whether you need to adjust scope, time, budget, or other factors to get to at least an 80% confidence interval in your estimates.
  5. Contract with your vendors on something other than a time-and-materials basis if you are trying to "toss work over the wall" to them, or trying to make them accountable for estimates.
  6. If you can't get the contractual guarantees you want (and it probably won't help you as much as you think even if you do), consider a more-collaborative approach where you're doing things in short, easy-to-estimate pieces that allow you to replan and reallocate as you go along. NB: This is the essence of agile frameworks like Scrum.

By ensuring that you plan based on your available budget, and on the resources available to you, you'll end up with a more accurate estimate than if you tried to leverage someone else's timelines or budget. More importantly, by having the task performers estimate their own work, you'll get a more accurate sense of how likely it is that you'll reach your budget or schedule targets than if you impose those numbers by fiat. You may be unhappy with those numbers, or pleasantly surprised that something will be cheaper or faster than you originally supposed, but in either case you will be tracking against a likelier outcome than someone else's average.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.