Project Management
Posted by Kurt on Tuesday, May 25, 2010 in category:
Well, the framework from my last post is going to be one of those low and slow projects, it may never even come to fruition. After I wrote that post I came back the next day and discovered a few major errors in how I had conceived the architecture. Whatever. I still want to do it, but I want to get the project management solution finished more. I cast around for a solution and CodeIgniter came up. I found an ORM for it that I’m not entirely happy with but that I believe will work decently (DataMapper with DMZ).
Basically the problem with any ORM is that it needs to have your database structure mirrored so that you can manipulate the data and build queries in a way that mimics the database itself without actually touching the data until the moment you need it. DM/DMZ have a rather verbose method of representing this with lots of nested arrays and it’s a pain, but after it’s set up, working with it is really decent if a bit too magical. So my odyssey has begun in creating the data structures as code. This post is not supposed to be about that, it’s supposed to be a transcription of my ideas and notes that I’ve been constantly referring to. So here we go…
We are a design company, not a software development company. Our needs in project management are a little different and often smaller, even when we do software development. The working title for this project is Yams. It doesn’t mean anything. No, it does not mean ‘Yet Another …’ it means the root plant that is orange and tastes very good when baked/boiled/whatever. My goals in building Yams are to start simple but generalize everything so it’s easy to add features later. Yams is designed for a group of people who do projects of any sort to upload it to their own web server, have a user account for each person, and manage responsibilities per user. Let’s break it down.
Users
Typical user system with privileges. It’s number based, 0-10 with registered users occupying 1-9, guests occupying 0, and admins occupying 10. I haven’t put much thought into this part of it yet but I have a vague idea that users will start at level 5 or something by default, most tasks in the system will require level 5 by default, but if you want more user classes you can define them as higher or lower and then change the required access level for tasks as an admin. This is all really nebulous and not planned out at all right now so let’s move on.
Accounts
We separate our projects into accounts. Accounts are companies or people or whatever that we do work for. They are not user accounts in the system, those are the Users from above. This is really a top-level object and lots of things will belong to them. Accounts do have an owner who is a User and a primary contact who is a Contact. On the account summary screen, the primary contact’s email and phone will be used. I’m not sure yet if it’s a good idea to also have a phone number and email for the Account itself, but if so then it’s a trivial task to add them. This object has a notes field that can be used to store miscellaneous data. This can be used as a crutch to store data that should go in custom fields. I want to make custom fields ala Salesforce a feature but more on that below.
Contacts
This object is a single person that we need to talk to when working on a project. Many of these Contacts may belong to a single Account. A Contact may even be linked to multiple Accounts, but that’s not a typical scenario. On the Contact edit screen, I’m thinking a drop down box to select which Account the Contact belongs to with a JS-enabled (+) button that adds a second drop down. This object stores a first/last name, full address, phones, and email.
Projects
A Project is a collection of tasks. It belongs to a single Account and has a primary Contact that defaults to the primary Contact for the Account. It may only use Contacts from that Account. Dynamically populated drop down boxes everywhere. Projects can belong to Categories. I won’t dignify Categories with a section, but Yams will allow users to add Categories in a rather standard system. Each project has a status: ‘Not Started’, ‘In Progress’, ‘Completed’, ‘Deactivated’. It also stores a start date and an end or due date. A notes field is present here as well.
Tasks
Tasks are a major workhorse object. One or more Users are assigned a Task as being responsible for completing it. Each Task has a start date and due date as well as an hours field that may be used initially to estimate project length and later edited to reflect how much time was actually spent. In the future this functionality will be much expanded, perhaps with a desktop app (AIR maybe) and hours will be broken down by user. Tasks can also depend on each other. A major goal of this application as will be discussed in the major features section is a timeline view for projects. There’s a fancy name for these graphs that I can’t think of right now, but Yams will do that. In order for the feature to be automatic and magic-cool, Tasks need to be structured in a tree of sorts. More on this in the features section.
Quotes/Invoices (Itemlists)
I want this system to enable rapid quote and invoice generation from a project or projects. Itemlist is the name for these objects since they are essentially identical. Itemlists are versioned, if you make changes to one it creates a copy and changes the creation date and invoice number if applicable. It marks the old one as obsolete and notes what Items you added or deleted from it as well as an optional revision notes field from the User. In addition to storing whether it’s an invoice or quote and if it’s a current revision, invoice Itemlists make note if payment has been received.
Items
Items are another workhorse object. They also have a tree structure that will probably be limited in the application logic to 3 levels. An Item belongs to one or more Itemlists. Items may be either independent and store a description or they may be an alias for a Task which uses the Task’s description. This allows Users to see if their project has been correctly billed in the end. Perhaps there will be a mechanism to mark a Task as not needing to be invoiced on the screen where projects are converted to invoices or quotes. Items also store an optional image file which is an image of that particular task. For design work on a small scale, a Project may consist of many Tasks that are themselves mini projects. I look to one of our biggest clients that has us do miscellaneous small design projects and each one would be one Task in this paradigm, which means this project would have multiple images, but each Task/Item need not.
Phew. That about covers the major structures as we’ve planned them out so far. I think I will make another post later defining the major features we want Yams to have and the rationale for each. I’m way too zazzed after those 1200 words to write decently in this update.
THX that’s a great aswner!
XWx8mf brjgxxbxhzms
GHzFqp , [url=http://epqogfdlrrfo.com/]epqogfdlrrfo[/url], [link=http://zmmioqrzmeph.com/]zmmioqrzmeph[/link], http://qoslkqwhgwtg.com/
Admin – I’m Rich from SEOPlugins.org… Do you want to double or triple your click-through-rates on your Ads? If YES, you need to check out our review of the latest click-through-rate optimized WordPress Theme. http://www.seoplugins.org/ultimate-wordpress-theme/
Obtained some wonderful information from you and this will help to get rid of my worries cheers!