AnyStandard.net
Please Visit
Virtual Project Leader
Another site to help out
the business world.
As a Project Leader we need a way of keeping a project accurate, progressive and on-time. This can be a
challenge with all the responsibilities of a Project Leader. One way of coping with these responsibilities is
to be able to find what you need in a timely manner. This site will help you with some of those challenges.
I will reference this site periodically to help me remind myself what else needs to be done.
There are tips on creating an Initiation Document, Feasibility Document, Design Documents. Making other
reports available like a Request for Proposal(RFP) or a Test Exit Report. Each of the reports are down
loadable in a format ready to fill-in. Some of the time consuming tasks are just trying to determine what to
write. Now you will have the outline and all you need to do is fill in the rest.
We will cover quite a few topics and this list below will help you navigate to those topics.
Why an RFP? Depending on the requirement, you may have a need to
formally send a request to an outside developer and in some cases
request to have one filled out by your internal departments. The need will
be determined by whatever policies your business sets.
An RFP has information of the Purpose of the request, a background of
what currently is being done, resources needed, time incurred, with
examples. Explain why a change is needed. This will help the developers
stay focused on the request and avoid creating the same issues.
Also include the Technical Requirements, Selection Criteria, Review
Criteria. It is necessary to mention the RFP Process that the project team
will follow in reviewing and approving proposals, as well as preliminary
information on the process that will take place once a proposal is selected.
Lastly the contact information.
A Project Leaders biggest tool is the Project Plan. A list of tasks needing to
be completed. Attached with each task is usually a resource or resources
that are assigned to this task, duration of the tasks along with the
scheduled start date. Some tasks may have a predecessor. These are the
most critical pieces of the task.
Other columns that are helpful are the completion percentages, Constraint
dates, Milestones and maybe one or two more but after that I feel you may
be micro managing the project. There are abilities of putting cost on each
task but when you start to work the plan this information gets to be a full
time job. You can’t make managing a project plan critical path to the
project.
When filling out a plan a visual Gantt Chart will help display your project
over time.
An Initiation Document will set the pace for you project. An official
document meant to determine what is actually needed. Along with the
definition are official committed signatures from significant members of the
organization.
This document requires a background of the project. Not to repeat what is
already stated, using the same background from the RFP will suffice. The
start of the project should have a Product Definition that includes a
Purpose, Objective, Scope, Deliverables, and Constraints. Present a
Business Case including Project Benefits, Options, Cost and Time Scale
with Costs and Cost Benefits. Provide a Risk Analysis including Risk
Identification, Risk Prevention, Risk Management, and Risk Monitoring.
Present the Roles and Responsibilities showing Project Leader, Business
Analyst, in the case of Agile Project management an Architect Owner,
Product Owners, Team Lead and Project Teams are needed.
As mentioned above the Project Organization Chart/ Structure Diagram this
group will commit to the project.
Is the project even feasible to do? Is it cost justified? Can the project be
finished on-time? Is there a return on the investment? Will you get more
savings in return than the cost of designing and developing the process?
All these questions need to be answered.
In the feasibility phase you need to identify your resources for the tasks to
come. At the same time you need to check any competing projects that will
interfere with the resources you need.
The feasibility can have information of a Market Analysis to understand the
environment in which you will compete. A Technical Analysis of the AS-IS,
Gap Analysis, Benefit Analysis. Whether or not there are qualified
resources to work on the project. Available Application resources,
available hardware, available storage capacity. A Financial Analysis can
help your decision.
The initial Risk Assessment attempts to identify, characterize, prioritize and
document, a mitigation approach relative to those risks which can be
identified prior to the start of the project.
Time and Recourses, expected implementation and available resources.
Compiling all this information will determine a GO/NoGO for the project.
When in the design phase of your project it is best to be explicit about
what is going to be done. 11 topic are covered in this document.
1) The Executive Summary. Reiterate the business objectives and benefits
of the project. 2) A Design overview for the whole project. Including a
Functional Overview and an IS Overview.
3) For each task defined, there should be a System Design, including the
Module design, 4) Processing Description, 5) System Inputs, 6) System
Outputs, 7) File Structure/D.B. Description. Topics 3,4,5,6 and 7 are
repeated for each module.
Finally, 8) Control Provisions, 9) Security Provisions 10) Backup and
Recovery and 11) any Manual Procedures needed.
This document will serve as documentation for the business and for the
next AS-IS task needed for the next project.
Testing is probably the largest description of any of these requirements.
In fact we have dedicated a page and it is best to provide a link to the
detail explanation of what is involved in testing.
www.AnyStandard.net/testing.html .
This Text Exit Report will be used to validate the changes in the software.
Noting the Approval of the test will confirm the change is ready for
implementation. Keeping a version history if the test not only complies
with Sarbanes/Oxley but shows the effort in the testing. The System Test
Plan will describe each script to be performed by the tester with PASS/FAIL
results. The Test Assessment can give a summary of the test, and show
defects analysis. Outstanding issues will provide a Defect summary and an
action plan listing the outstanding defects, the impact and a planned
resolution.
A Project Leader will achieve results with a great plan of action. Along with
a plan you will also have to motivate people by accomplishing the plan in
an organized manner. You can depend on your insights but without some
direction, mistakes can be made. Take these documents and use them to
your advantage. Not only will it make the team aware of your project,
your sponsors will also benefit from them. A plan will keep you focused
and generate urgency to keep you focused. A formal request or just an
Email will start the project but without a supporting Initiation, Feasibility
Analysis, and Design Documents you could end up with an incomplete
product and inevitably end up with request changes. The project did not
plan for those changes and the cost of the project just went up,
The Waterfall Model is a linear-sequential life cycle model, designed with 8
major steps. Initiation, Feasibility, Analysis, Design, Develop, Test,
Implement, and Post Implementation. Each phase a must be completed
before the next phase can begin and there is no overlapping in the
phases. This was originally the approach for a Project Leader but was
never really followed to the letter. When it came to the full integration test
some functions seem to be forgot, so it was back to the design and
development phases. This model seemed best fit for large scale projects.
Smaller projects made this process look like over kill.
There are many different types of Project Management models. I would only like to focus on 5 of them.
Traditional SDLC Waterfall, Iterative, Spiral, Extreme(RAD), and Agile. Each one has their own place and
purpose. The following demonstrations is an explanation of each approach with potential types of projects
for their use. Research each of them and find the one that will fit your needs.
Reports and Models are only part of what a Project Leader needs. She/He needs to be what the title says. A
“Leader”. A leader of a great team. A Project Leader needs to find the best traits of the team. Find a way to
motivate the team. Build relationships, and be aware of the projects progress at the same time.
Ask the team how they feel the project is progressing. Not only will you learn from them, you will build a
closer relationship with the team. You will be able to analyze your risks and empower others with insight
from all. Communication will let you achieve results.
The definition of Iterative is involving repetition. With the Iterative Model,
it is just that. Following the same life cycle steps continuously until the job
is finished. The requirements phase is where the preliminary analysis is
done, then determine what to design, develop, test and implement.
Potential new functions or required enhancement will repeat the same
process. Design, develop, test and implement. This model was used to
help me improve this site.
Similar to the Iterative Model the Agile Model is done in repetitive cycles
of sprints or iterations. The differences are involving the business
product owner and the team as a whole and better decide the approach of
what tasks to be delivered. This model restructures the overall approach
to Project Management. It allows the business to see what the business
needs earlier with a cohesive design and production. The Project Leader
shifted to the Team Leader teaching the rest on how to deliver a Project.
This knowledge is then used for the next project. What better way to go
than to breed for the next adventure. I also challenge everyone to check
out Disciplined Agile Delivery.
Extreme(RAD) Model. The acronym stands for Rapid Application
Development. Extreme, in the way of trying something new, like
developing a process without any specific planning. This may seem
unorthodox but it actually can work as long as you have the right
resources. The right individuals to gather the requirements to build
prototypes that can quickly be turned into a production process. Your
product may be delivered in a speedy manner which is good but there are
serious risks. Time may not permit changes needed after the
implementation. I chose to use one of my YouTube presentations as an
example. Created using EZVID and simply uploading using the software
provided.
After using the traditional SDLC Waterfall model and trying an Iterative
SDLC model, a twist was put on using both of them. Split the 8 groups into
4 sectors. Identification, Design, Develop and then Evaluate. Spinning
back into the next prototype. Include Risk Analysis and determine how to
integrate all the other design and developments for the project. This
allows the linear approach of the SDLC Waterfall model to be followed but
also gives the project to be delivered in iterations. You can see the
evolution of Project Management changing and knowing there will be more
change to come. This link gives an excellent representation.
Virtual Project Leader
Copyright R. M. Wideman © 2003. Reproduced with permission.
A statement of work Is another way the business will communicate.
A formal document that captures and defines the work activities. It will
include a background, purpose or objective, potential benefits. This
should also include a detailed Scope with requirements. A project
schedule with milestones of deliverables can also be helpful. The project
budget would include Agency Labor, Contract Labor, and if needing to note
Non-Labor Cost. List the names of the Organizational Units for the Project
Implementation Cost Responsibility. Include Risk assessment, and
Approvals from the proper department heads.
There are many examples of the Statement of work. It would be best to
search the web for one that fits your needs.
The state of North Carolina has a great example of a Statement of Work
Functional requirements are the technical details that define what a system
is supposed to accomplish. Generally, functional requirements show the
Business Requirements including the Business Value or Purpose, The
customer needs, and Existing Functionality. Other sections include System
requirements, Business Approach, Technical Approach, Functional
Specifications, Constraints, Assumptions and Caveats
est. Nov 2013