From Dwayne Wright - Certified FileMaker 10 Developer
WEB:
www.dwaynewright.comEMAIL:
info@dwaynewright.comTWITTER:
dwaynewright Just spent some quality time reading up on classic waterfall project management areas and wondering at what level they are used in most typical FileMaker projects. Now defining what is a typical FileMaker project is a challenge into itself. The nine define project areas as defined by the Project Management Body Of Knowledge are ...
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Project Human Resource Management
Project Communications Management
Project Risk Management
Project Procurement Management
I would say that one defining difference in a FileMaker project is that it is normally smaller in scope, requires more flexibility and has more restrained resources at its command. Larger projects tend to have a larger number of diverse stakeholders, more complex communication needs, a more formal change control process, larger number of activities to track and have more potential risks to consider.
In a well managed waterfall project, the project manager will decide which of the above processes need to be included in the overall project management plan. Here are a few of the processes that I’ve rarely seen in an official project management plan for a FileMaker project.
Project Quality Management
Project Human Resource Management
Project Communications Management
Project Risk Management
Project Procurement Management
It may sound awful but I have to say that scope, time and cost are generally lumped together in the same document typically called the project estimate. The estimate is by no means should be considered “a plan” but the estimate may be the only thing created before works starts on a FileMaker project.
The integration management plan is another document that is rarely seen in a FileMaker project and in particular when the project management is primarily done by the same person doing the FileMaker design. Although the project integration may not exist in a physical sense, it most surely exists within the noggin of the FileMaker Developer / Project Manager. Depending on the experience and talent of said developer, the project may not reach the expectations of its audience.
A formal written integration plan (which is largely the collection of other needed management plans) is a great aid to a project. Particularly if the plan is signed off by the customer! The creation of and authorization of a formal integration plan helps insure the overall success of the project. Thing is, this type of documentation takes time and time is money. Also, this type of documenting effort is generally shunned by a developer that just wants to start wrangling those pixels into shape.
That is it for now but I will likely publish other thoughts about how the worlds of waterfall project management and the typical FileMaker project collide ( or don’t as the case may be).
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.
© 2009 - Dwayne Wright - dwaynewright.com
The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.
ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit
http://www.dwaynewright.com/donate.html
Posts
