by PMHut Team | Jan 18, 2012 | Project Lifecycle Phases
The Implementation Phase in Project Management
By Jessica Popp
In its simplest form, Implementation is generally considered by team members as when the project starts. In a phase-controlled project, project team members are only minimally involved prior to the implementation phase. At this point, the scope should be approved and the project is starting in earnest. Implementation is very often the longest phase in the project lifecycle.
From a software perspective the traditionally agreed upon sub-phases include requirements, design, develop/build, and test. These can be extrapolated in many different ways and approached using different methodologies such as Agile, XP or countless others. But, at the core of the project you are managing these four things:
- Understanding in a documented way what the end customer needs/wants (Requirements)
- Extrapolating the understanding of the requirements into a technical specification to prove that the wants and needs of the customer can be addressed (Design)
- Making the requirements a reality (Development/Build)
- Test the results for accuracy/completion (Quality Assurance or Testing)
I’ve stated the above bullets in a generic way to demonstrate that these sub-phases or something similar are applicable across many disciplines. Read the Complete Article
by PMHut Team | May 16, 2009 | Project Lifecycle Phases, Project Plan Development
Project Lifecycle Overview – Part I (#1 in the series Project Lifecycle Overview)
By Jessica Popp
A picture is worth a thousand words so I thought I would start with a diagram. I recently had the need to explain an overview of the Project Lifecycle within the context of software development so I thought it would be worth sharing here. This diagram is by no means original or even possibly unique. The initiating, planning, executing (implementation), monitor and control and closing match the PMBOK definition for project process and the sub-processes are generally agreed upon across the industry, but everyone enjoys a good picture and so here is mine for explaining how things work.
While some of the sub-processes may software specific (HLD, DLD, system testing to name a few) the overall process is applicable to any field of interest. Here I will talk about the main processes (Initiation, Planning, Implementation, Monitor and Control and Closing). Read the Complete Article
by PMHut Team | Dec 9, 2008 | Requirements Management
Must-Have vs. Nice-to-Have Requirements
By Jessica Popp
In addition to checking for solid requirements using the SMART methodology it is important to properly prioritize or categorize the project requirements. This can become especially critical in the large project or project with seemingly unrealistic expectations. There are many ways to categorize these; personally I like to apply the easily understood labels of must-have and nice-to-have.
This method is easily understood by the customer and provides the project manager with a significant amount of latitude for negotiation later in the project, the importance of which cannot be underestimated.
So the way it works is quite simple. After all of the requirements have been recorded, the list is re-visited with the customer to specify each requirement individually as must-have or nice-to-have.
- Must-Have: this is any requirement that absolutely has to be delivered for the project to be considered successful. This helps create the base set of expectations with the customer.
Read the Complete Article
by PMHut Team | Oct 13, 2008 | Project Management for Beginners
Project Example: The Triple Constraint in Project Management
By Jessica Popp
My goal with the project example is to create a scenario that is similar to those faced in real projects. I find, too often, that textbook examples overly simplify scenarios to the point that the answer is so obvious that when faced with a real world example the less experienced project manager cannot distill the issue.
Mark is a project manager for Custom BoatBuilders, Inc.1 Bill manages the custom building of boats for private consumers. Consumers contract with Custom BoatBuilders (CBB) to build custom watercraft for personal use. Mark reports to Steven who is the Client Relationship Manager. Steven’s responsibility is to work directly with the customer and secure a contract for the building of a custom boat. After a new customer contract is signed, Steven involves Bill to execute on the project.
Steven presents Mark with the parameters of the project. Read the Complete Article
by PMHut Team | Aug 24, 2008 | Requirements Management
SMART Requirements – Time-bound (Timely, Traceable) (#6 in the series SMART Requirements)
By Jessica Popp
Time-Bound (timely, Traceable): where appropriate each requirement should be time-bound or specify by when or how fast a requirement needs to be completed or executed. In software engineering, you may see the “T” in SMART being used to mark whether a requirement is “traceable”, which is my opinion is a separate but important topic in developing software. For this general requirements overview, the focus will be on the time-bound requirement.
Read the Complete Article
by PMHut Team | Aug 14, 2008 | Requirements Management
SMART Requirements – Measurable (#3 in the series SMART Requirements)
By Jessica Popp
Measurable: this answers whether you will be able to verify the completion of the project. You should avoid signing up for any requirement that cannot be verified as complete. These are especially risky when you use non-quantitative terms (best, optimal, fastest) for acceptance criteria.
- Weak Requirement: The system shall have an optimal response time for the end-user.
Why is it weak? There is no way you can be successful with this requirement once the new system goes into production. It’s similar to being specific, in that optimal is not defined and really cannot be defined.
-
Strong Requirement: The system shall have user response times on user click-events that are 5-seconds or less during business hours of 9AM-5PM, Mountain Time, Monday-Friday.
Now this requirement can be measured once the system is in production. In the first example, you might end up in a never ending loop with the customer after the system is in production trying to define “optimal.”
Jessica Popp is a practicing project manager in software engineering. Read the Complete Article
by PMHut Team | Aug 12, 2008 | Requirements Management
SMART Requirements – Specific (#2 in the series SMART Requirements)
By Jessica Popp
Specific: a good requirement is specific and not generic. It should not be open to mis-interpretation when read by others. This is the most important attribute to get correct. Avoid using conjunctions (and, or, but) as they can confuse or misconstrue the meaning. Avoid indeterminate amounts of time (soon, fast, later, immediately) as they are open to wide mis-interpretation which results in dissatisfied customers.
- Weak Requirement: The report displays all the monthly data from the marketing department.
Why it is weak: Anytime you see all, always, never and other global adjectives, beware. What if the marketing dept adds more data; do you need to immediately update the report? What if “all the data” that you are aware of from marketing is different than what your customer (the report requester) perceives as “all the data”? Even if you and the customer agree, what about a third reader?
Read the Complete Article
by PMHut Team | Aug 11, 2008 | Project Plan Refinement, Requirements Management
SMART Requirements – Introduction (#1 in the series SMART Requirements)
By Jessica Popp
In my opinion, requirements are the most under-rated aspect of most projects. In an unbelievable number of corporate projects they are completely non-existent and in the vast majority they are really no more than a paragraph or two of high-level requests which are unlikely to be delivered on successfully. In a very few of the countless projects I have worked on I have seen adequate, or an attempt at adequate, requirements. These projects, without fail, are the most successful projects that I have seen.
Why the passion, you ask? Without clear, complete and agreed upon requirements there is almost zero-chance, yes zero, that the project will be delivered successfully. And when I say successfully, I mean on-time, on-budget and matching the desired scope. Sure, most projects will get delivered without good requirements but you will see project delays (possibly numerous), budget overruns, and final scope that doesn’t satisfy the customer. Read the Complete Article
by PMHut Team | Aug 4, 2008 | Project Management Definitions
The Triple Constraint
By Jessica Popp
Ah, the triple constraint, the cornerstone of project management and project management (PM) lingo. Along the way, I will try to cover the most common acronyms and lingo that are used in the discipline. I neither intend to promote nor condone any particular use, or in many cases, overuse, of project management lingo. My goal is to create familiarity with the terms as they are commonly used in practice.
The triple constraint refers to the three inputs that govern the ability to deliver a project. The three commonly agreed upon constraints are budget, time, and scope. They are often drawn in a triangular shape to represent the relationship between them. This triangular arrangement helps to represent that any adjustment to one of these factors will have an impact on the other two. This relationship will become clearer with examples. Let’s start with definitions:
Budget – the allowed funds (money) that can be used to complete the project. Read the Complete Article
by PMHut Team | Jul 13, 2008
PM Hut currently has 570 contributors! Please contact us in case you’re interested in publishing your Project Management articles on PM Hut and joining the list below!
An article published on PM Hut may be eligible for PMI PDU credits under the Category D of the CCR Program (Giving Back to the Profession). This category is capped to 45 PDUs per 3 years. Authors claiming their PM Hut published articles for PMI PDUs are required (by PMI) to supply PM Hut’s physical address in their application. Please contact us for this information.
Please note that it is the responsibility of the author to handle the whole process for claiming the PDUs, PM Hut’s role is currently only limited to supplying its own physical address to the author.
Read the Complete Article
