Idea #4: Project Artifact Management
There’s a small civil engineering firm in southern California that hires me occasionally to do some freelance software development. Their core business is the production of a really specialized kind of 3D visualization for large construction projects.
Before they can get started on one of their projects, they request a set of files from their clients: CAD drawings, survey data, seismic readings, etc. The client provides those resources, along with notes and annotations describing the contents of each file. In addition, they submit requests for special kinds of output files: paving plans, cut/fill contour maps, photo-realistic renderings.
You get the idea.
When the project manager receives the customer data, the relevant technical resources get passed to an engineer who starts working on the new drawings. During the project timeline, the engineer might request additional resources from the client or instructions from the project manager. The original files get more and more annotations. The engineer produces rough drafts of the project deliverables.
Of course, a project manager will want to make notes here and there, and the client will want to provide feedback on each draft. During this whole process, an administrator might need to audit the access logs of the files. Different users have different permissions, and various project resources are controlled under restricted access.
Finally, when the client is satisfied with the project deliverables, all of the files and documents are archvied for future reference, and a new Astrodome get built somewhere. Or whatever.
At least, that’s the way things should work.
Over the last year and a half, I’ve been hired to put certain pieces of this functionality into place. I’ve developed a simple web-facing application so that the engineers can pass files back and forth with their clients. Each file is accompanied by a set of instructions and some metadata about the client’s company (contact person, email, phone) and the project (deadline, project ID). File access is restricted to certain users, and a complete download-log is kept for all files in the system. There’s also an administrative account with a few special privileges.
It’s definitely not a complete product. In its present state, the software is primarily a file-management system with a few custom fields. Nothing too sophisticated.
But working on this project has given me a slew of ideas for a more sophisticated Project Artifact Management system.
Some feature I think would be important:
- Each user should have a dashboard with status information about the project, and with notifications regarding any deliverables currently due.
- The system should be able to handle the notion of multiple different teams working on a project together (not just a “company” and a “client”).
- A user should be able to publish certain resources, as well as request resources from other project collaborators.
- A user should be able to define a questionnaire to gather requirements for the project.
- It should be possible to attach a questionnaire to certain project resources. (files, documents, etc.)
- It should be possible to divide any project into a set of sub-projects.
- Project resources (files, documents, etc.) should be flagged with to indicate their status. These flags could be used to pass a document through the organization
(flagged as: First Draft, Final Draft, Ready for Prototype, etc). - Project resources (and their annotations) should be versioned, and it should be possible to query the system for previous revisions of any resource.
Actually…it’s hard for me to stop writing features. The possibilities are so broad for a project like this. If I decide to develop this software, I’ll need to carefully specify a feature-development timeline so that I don’t get bogged down trying to cram everything into a 1.0 version of the product.
Market Potential
The number of potential clients for a product like this is staggering.
A few years ago, I was talking to a criminal investigator who told me that he could really use a piece of software like this. A complex investigation can have hundreds of pieces of evidence and many more supporting documents. Dozens of different experts can contribute documents (or other kinds of artifacts) into the investigation.
Access control would be extremely important in that kind of environment, since, for example, the scientist at the hair-and-fiber laboratory should never be exposed to any of the other details of the investigation. Her only concern should be to write an analytical report for Specimen #ABC123 and submit it into the system.
So, I think there’s definitely a market for this kind of product. Especially if I can successfully develop the software with a user metaphor that remains agnostic to any particular problem-domain. In other words, the software should be equally effective in modeling the project management process for civil engineers and for homocide detectives.
Competition
The closest competitor (that I’m aware of) is Microsoft SharePoint, though even SharePoint still seems like a product for software companies, and that’s not what I’m envisioning. There’s also an open source project called Scarab that describes itself as an “artifact tracking system”, but it concerns itself with artifact types like “Defect”, “Enhancement”, and “Requirement”, so it still seems like just another bug-tracking system for software developers.
As far as I can tell (in five minutes of research), there are no competitors. Every so-called artifact management application that I can find is specifically designed to meet the needs of software-development projects.
But there are other kinds of projects out there.
And those projects have artifacts.
And those artifacts need to be managed.
Without being able to easily identify any competitors, it’s difficult for me to determine even a ballpark price-point. It’s unlikely that my friends at the civil engineering company would have been willing to pay more than a thousand dollars for the software (even though they’ve paid me more than that in consulting fees). This is the kind of product that would probably benefit from a tiered pricing structure, with license-management based on the number of distinct user accounts supported by the system. (And probably an extremely inexpensive “lightweight” version of the product, just to capture some revenue from the bottom tier.)
Assuming an average sales price of around $1000, I’d need to sell about five licenses per week in order to meet my annual revenue target of $250,000. That seems very doable.
Then again, an average sales price of $500 would only require nine new licenses per week, and I think that might be even more doable. Though I guess it depends on the price-elasticity of demand for artifact management software.
…Shrug…
Pros:
- I’ve been working on a simple version of this software for almost two years, on and off. I’ve already discovered a few gotchas and solved some of the rudimentary problems.
- It’s likely that my friends at the civil engineering company would be willing to beta-test the software, providing lots of information about their workflow.
- This type of software would lend itself well to future improvement, so it’s easy to envision a simple first version and an incremental upgrade path based on customer feature demand.
- Nearly every kind of business organizes its work into some sort of “project” concept. And most projects involve a heterogeneous collection of files, documents, and annotations. Although software companies have largely solved this problem with source code repositories and bug-tracking databases, many other industries lack a well-though-out methodology for managing project resources.
Cons:
- Unlike a product that solves a problem in a particular problem domain, this product would strive to be universally applicable. As such, it might be difficult to convince companies in many different industries that the software could be customized to meet their needs.
- Marketing might be tricky. I think I have a good grasp on techniques of marketing software to computer geeks, but not to other industries. I’m not sure how I’d promote the product, and I’d probably need to find someone with expertise in selling software to other industries.
- It might be difficult for many people to grasp the difference between project management (schedules, gantt charts, budgets) and project artifact management (designs, files, documents, etc), so I’d have to make an extra effort to explain the difference.
…
This is the fourth of 30 business ideas that I’ll be writing about over the course of 30 days. Some of the ideas are brand-spanking-new to the marketplace. Some of them would require me to differentiate my product from a sea of competitors. One of them will become a product over the next six months, and the foundation of my new software business.
June 14th, 2006 at 12:57 am
I agree that trying to make a “universally applicable” product has its difficulties. Instead of adding more and more custom features as you start to apply the product to different problem domains, you would want to sharpen the focus of your product. For instance, if your product is not for product management, don’t stray into that feature set.
Make sure a simple demo of your product is very compelling in solving the core problem. This will get people excited and get them thinking about how it could meet their specific needs.
June 14th, 2006 at 1:07 am
It sounds good, I just want to point that this app is very related to the document handling. My wife works in a pharmaceutical company, its register departmens handles a lot of documents, versions and specifications that must be sended to the auhtorities. They work with a very well known software that covers exactly this niche, I don’t remember the name, may be something as “Documentum” or similar … I’m sorry to not remember.
(If you have the book “Crossing the Chasm” this company is shown as a sample of a very expensive product with very few clients, and that it used the pharmaceutical sector as a headbeach to span to other sectors a general applications, very similar to yours).
June 14th, 2006 at 3:38 am
My thoughts were like Francesc’s. I used to work for a medical device manufacturer, and a FDA requirement is to keep a product history file.
We used eRoom, which was later purchased by Documentum, so it’s probably the product that Francesc is referring to. You can check it out here: http://software.emc.com/microsites/eRoom/index.jsp. IIRC, the software was in the 6-figure range to support a company with ~200 engineers.
One downside is that the market has a lot of players, but the upside is that most are targeting big installations. If you start with a niche and target SMB’s I think this would be a winner.
The other thing to consider is how you would advertise. The search engine space is very crowded for many of the key words associated with this type of product. It may be difficult to rise above the noise.
June 14th, 2006 at 5:47 am
This is an idea in search of an idea. Access control in these systems is a real pain especially with fluid membership, as companies and people in those companies constantly change. Users end up feeling that the system is standing in their way because someone hasn’t given someone’s temporary assistant the right access privileges… I’m not saying you don’t have some ideas about how to address this, it is just that this idea #4 is more the broad identification of a problem area than a specialized idea of how to deal with it. It is still very cool.
June 14th, 2006 at 5:49 am
It sounds really neat.
The reason why there aren’t any generic artifact management sw on the market might be because it is not easy at all to create this sort of thing generically! Or perhaps the creators of such sw did not have access to a broad range of clients, so they created sw tailored to whoever they were writing the application for.
This makes me wonder how Trump manages his projects. Does he have sw that allows him to dial into any of his ongoing projects and see their progress? Or does he have throngs of managers he talks to face to face? If I were in his position, I’d love to have a bunch of webcams following the whole thing. :)
June 14th, 2006 at 6:29 am
I like the idea.
The notion of project artifact is very compelling and you’re absolutely correct in that this could be applied across a broad range of industries. I don’t think that you’ll have too hard a job explaining what this is all about either – it’s just about managing and tracking the ‘things’ that are created as part of a project process.
Where you could really add value is traceability through your meta-data layer. Even on a small scale in my day-to-day job, finding project information that you just know was related to such and such an email or powerpoint can be a real chore and that’s with the help of things like ISYS and Google Desktop. Some time back I worked on a research project looking at, you guessed it, artifact management for software engineering. One of the most interesting things that dropped out of this was being able to create relationships between the artifacts.
The hard thing to balance is how generic your system will be. If it needs to much end-user configuration then some companies may not be able to invest the time to set it up. On the other hand, if it can’t be tweaked to an organisations needs it will be deemed too inflexible.
Looking forward to tomorrows post :-)
June 14th, 2006 at 7:13 am
Try a search for “extranet” or “extranet software”. That’s what they called it at my old company.
June 14th, 2006 at 7:51 am
Yep, Documentum is what I’ve always heard of being the big-ticket choice in this market. I’d also expect to get competition from workflow software; even though that’s more process-centric than document-centric, they end up doing a lot of document management.
June 14th, 2006 at 9:08 am
To me, this idea sounds like document management cross bred with light weight work flow management. Both of these segments are crowded and some of the document management solutions do provide some sort of ‘interaction’ between users. So what would be the main selling point of this solution? Probably a carefully chosen feature set from documentation management and work flow, but then again how would it stand out from the crowd specially if the target market is not well defined? Or will targeting some niche(s) be a better choice?
June 14th, 2006 at 11:02 am
Yeah, actually, I’ve heard of Documentum before. It sounds vaguely familiar, though I don’t know much about the software.
Check this out, though:
http://software.emc.com/products/software_az/index.jsp
There are currently 83 different “Documentum” branded products in their catalogue. Personally, if I were shopping for a project artifact management system for a small business environment (i.e., fewer than 500 employees), I’d be very turned off by the complexity of EMC’s product offering.
As a known framework-hater, my opinion is that under-architecture is almost always preferable to over-architecture. Simplicity nearly always trumps complexity. And the whole Documentum product landscape flies in the face of that preference.
I don’t think I’m the only one who feels that way. And I think I could leverage the complexity differential between my own software and the existing document management systems to sell more licenses.
August 1st, 2007 at 1:07 am
This is exactly what I expected to find out after reading the title Idea #4: Project Artifact Management. Thanks for informative article