When I was first asked to work on developing a project management tool, I stepped back and thought “Wow, what a huge responsibility!” and I have to admit, I was intimidated. But after thinking about it for a good while, I realized that I had worked on several other kinds of systems, some of which I liked and some of which I didn’t. I began to see this as a golden opportunity to build an application that took the best aspects of the good systems I had worked with and, hopefully, avoid the worst aspects of the systems I disliked. Such was the beginning of PPMlogx – the Portfolio Project Management application tool.
The first thing I needed to learn and understand was that this was to be a web-based application and not a piece of software designed to be installed and run on a desktop machine or from a large mainframe platform. This type of application plays by a different set of rules and requires that you know them if you want to referee disputes between the application and its users. I was paired up with a software engineer named “Mike”. Mike had a predisposition to explain just about everything he touched in terms of the decisions we made when building the first few screens of this new system. I was the same way. He’d had the same experiences with good and bad systems as I had and we shared the same opinions about some of them. The colors and the words to be chosen, the placement of the specific information within the screen frame, the branding and the logos to be used; oh, it was obvious that this guy had been around the block before (maybe even a couple of times) and that he knew what he was talking about. I knew immediately that we would wind up being good friends as this product developed and grew into a living, breathing thing.
And so it did. We have to take responsibility for it when it’s in a bad or uncooperative mood. Like a child that picks up bad behaviors from the parent he observes, we have to hold ourselves accountable for the mistakes we make in designing workflows or the bad behaviors we find ourselves building into this system. At one point, a user called me out and asked me why we had put a particular field on the screen she was responsible for completing when it was actually her manager’s job to supply the information for that field. Did I expect her to simply guess at a value and put it out there in hopes that someone would come along later and correct it? She was right – a change was needed and things flowed more intuitively in the tool once that small, simple correction had been made. I was guilty of exactly what I’d hoped to avoid – incorporating something I’d seen in another system that I had disliked. It’s like telling your child to do as I say, not as I do…
Trying to build an application that is to be used by a single industry segment and yet keep it generic enough to be used by clients that work in other industry segments is a difficult task. Almost every industry is uniquely jargon-laden and full of regulatory requirements. The art is in finding the common aspects of project management and making your system able to accommodate any and all of them. Whether a project is related to education or finance or manufacturing or healthcare; it still must have a specific start and end date, a timeframe with milestones and benchmarks for the team to complete the necessary work, risks and issues, and a budget and schedule to be adhered to in completing that work. Documenting those things in a project management tool requires good planning and makes that planning available for all to see so there are no surprises when it comes to delivering the finished project on time and within budget, all the while preparing for and mitigating risks should the worst possible scenario take place.
Want more information about PPMlogx? Contact us!
You must be logged in to post a comment.