|
Management Knowledge Base
Introduction
How important is management?
Management is critical to the success of institutions, projects or even a trip
or a vacation. Management performs planning, organizing, staffing, leading,
directing, controlling, monitoring, budgeting, testing, documentation and
motivation. in short, management is the difference between making it or breaking it.
The Art and The Science of Management
Management is both an art and science. The art includes God given talent
such as looks, height, soft skills, passion, the ability to lead and interpersonal
skills. Science is the fact that managers must have the knowledge of every
aspect of their projects. In the case they are lacking any aspect, then they
must search, learn, ask the experts and administrated to the experts. For
example, a manager is like a restaurant owner who must manage his restaurant
or hire experts to handle what he may not be able to do. Managers must take
ownership of their projects. In the real world, the science part of
management is too much to handle. Therefore we created our Project Management Planner
(PMP) Framework as our aid to the science part of management. Our PMP was
designed to have templates, trainings and tutorials to build and document
projects. There is training and documentation on how to use our PMP.
Our PMP is created based on Project Management Institute (PMI)® - Approach (processes).
The goal of this page is to present our PMP documentation listings of plans, document
and methodologies of both projects and management. Project and management teams
can use our listing as a checklist of their projects and management plans and documentation.
This page is also our analysis for building an automated and intelligent PMP.
We are covering the following List in this page:
• Procurement
• Project Management (PM) Documentation
• Project Management (PM) Plans
• Deliverables
• Statement of Work (SOW):
• Unified Modeling Language (UML)
• Rational Unified Process (RUP)
• Agile
• Scrum
• Design Patterns
• Security
• Infrastructure
• DevOps
• Prototypes and Designing and Building Projects' Websites
Procurement:
Bases on the project size and complexity, PM needs to select the types of documents-contracts
which will be presented to the clients for both negotiation and approval. These documents-contracts
will be created using our templates and they will be the basis for dealing with the clients:
Statement of
|
•
Purpose of plan
|
•
Scope of plan
|
•
Project background
|
|
•
References
|
|
|
Scheduling
|
•
Start-End dates
|
•
Milestones and phases
|
•
Release date
|
Purchasing
|
•
Types of goods & services
|
•
Make-or-buy decisions
|
•
Vender selection
|
Cost
|
• Performance based payments
|
• Cost of materials
|
• Fixing a unit of work
|
|
• The rate per unit of work
|
• Penalty for late payment
|
• Activity cost estimates
|
|
• Cost performance baseline
|
|
|
Performance
|
• Protest procedure
|
• Services options
|
• Performance criteria
|
|
• Terms and conditions
|
• Miscellaneous
|
|
Business
|
• Request for interest
|
• Invitation to partner
|
• Qualification guidelines
|
|
• Business-Driven solutions
|
• Confidential agreements
|
• Non-Confidential discussions
|
Management
|
•
Rules of engagement
|
•
Role/Responsibility matrix
|
•
PM plan updates
|
|
•
Scope baseline
|
•
Requirements
|
•
Teaming agreements
|
|
•
Risk register
|
•
Change requests
|
|
Development
|
•
Standards
|
•
Confidentiality
|
•
Warranties
|
|
•
List of deliverables
|
•
Licenses
|
•
Code ownership
|
Closing
|
•
Review of approval
|
•
Acceptance criteria
|
|
Project Management (PM) Documentation:
Documents
|
• Requirement
|
• Requirement Vision
|
• System Spec
|
|
• Analysis
|
• Technical Notes
|
• Assumptions
|
|
• Estimates
|
• Functional Design
|
• Code Documentation
|
|
• Components Interfaces
|
• Code interfaces
|
• Design Patterns Interfaces
|
|
• Conflicts
|
• Questions and Concerns
|
• Business Analysis
|
|
• Market Research
|
• Business Links
|
|
Change Control
|
• Changes Request Document Forms
|
• Changes Request Document Processes
|
• Release Notes
|
|
Closing
|
• Administrative Closure
|
• Contract Close out
|
• Project Review
|
Model
|
• Business Model
|
• Data Model
|
• Design Models
|
|
• Processes Models
|
• MVC Model
|
• Test Models
|
Development
|
• Architect-Design
|
• Business Rules
|
• Business Use Cases
|
|
• Change Requests
|
• Code Review
|
• Database Design
|
|
• Diagrams
|
• Dictionary
|
• Development Documents
|
|
• Presentations
|
• Project Log
|
• Source
|
|
• Source Save
|
• Tasks
|
• Unit Test Use Cases
|
Project Management (PM) Plans:
PM Plans are created based on Project Management Institute (PMI)® - Approach (processes).
What we are presenting is the documents associated with each PM plan. We have created a template
for each of the document as both fill out template and also a guideline on how to create a plan
document.
Resource Plan
|
• Procurement Planning
|
• Resource Planning
|
|
Activity Plan
|
• Work Breakdown Structure
|
• Activity Definition
|
• Activity Sequencing
|
|
• Fast Tracking
|
• Parallel Tasks
|
• Precedence Diagram
|
|
• Identify Bottleneck
|
• Activity Duration Estimating
|
• Critical Path
|
|
• Gantt Chart
|
• Time Line
|
• Project Schedule
|
|
• Status Reports
|
|
|
Scope Plan
|
•
Baseline
|
• Scope Planning
|
• Scope Definition
|
|
• Future Expansion
|
|
|
Quality Plan
|
• Value Engineering
|
• Quality Planning
|
• Quality Control
|
|
• Quality Assurance
|
• Cost of Quality
|
• Scope Verification
|
|
• Project Plans Review
|
• Test Plans Review
|
• Monitoring Project Team
|
|
• Performance Reporting
|
• Documentation Review
|
|
Risk Plan
|
• Assumptions Analysis
|
• Risk Identification
|
• Qualitative Risk Analysis
|
|
• Quantitative Risk Analysis
|
• Quantitative Risk Analysis
|
• Impact
|
|
• Risk Management Planning
|
• Risk Acceptance
|
• Risk Avoidance
|
|
• Risk Transference
|
• Risk Monitoring and Controlling
|
|
Management Plan
|
• Critical Path
|
• Alternatives
|
• Master Schedule
|
|
• Matrix Organization
|
• Responsibility Assignment Matrix
|
• Resolving Conflicts
|
|
• Reverse
|
• Completing Requirement
|
• Effort
|
|
• Budgeting Project
|
• Stakeholder Consent
|
|
Budget Plan
|
• Cost Estimating
|
• Cost Curve
|
• Cost Variance
|
|
• Cost Budgeting
|
• Forecast Final Cost
|
|
Timeline
|
• Calendar
|
• Tracking
|
• Project Checklist
|
Deliverables:
Project Deliverables are tabular lists of the artifacts to be produced during the project,
with target delivery dates. This becomes project master deliverables list. It is also a great
way to keep track of who is responsible for what, and is a cross-reference to your Project Timeline.
Statement of Work (SOW):
A statement of work (SOW) is a document used in the Systems Development Life Cycle.
A software vendor or services company will send a SOW to notify a client of work about
to be undertaken and agreed pricing.
Dates
|
•
Start and finish date
|
•
Deliverables and Schedule
|
•
Identify concrete and measurable steps
|
Resources & Budget
|
•
Applicable Standards
|
•
Special Requirements
|
•
Develop scope
|
|
•
Location of Work
|
•
Estimate resources and budget needs
|
|
Priority and Risks
|
•
Have clear project priorities
|
•
Identify risks
|
•
Identify responsibilities
|
|
•
Open communication and cooperation
|
•
Basis for acceptance and authorization
|
•
Define project success
|
Milestones
|
• Major Milestones
|
• Master Schedule
|
• Milestone Schedule
|
Tasks
|
• Activities
|
• Artifacts
|
• Unit of work and Work Pages
|
Unified Modeling Language (UML):
The Unified Modeling Language (UML) is a general-purpose, developmental, modeling
language in the field of software engineering, that is intended to provide a standard
way to visualize the design of a system.
Unified Modeling language (UML) is a standardized modeling language enabling developers to
specify, visualize, construct and document artifacts of a software system. Thus, UML makes
these artifacts scalable, secure and robust in execution. UML is an important aspect involved
in object-oriented software development.
Diagrams
|
• Use case diagrams
|
• Class diagrams
|
• Object diagrams
|
|
• Sequence diagrams
|
• Collaboration diagrams
|
• Statechart diagrams
|
|
• Activity diagrams
|
• Component diagrams
|
• Deployment diagrams
|
Rational Unified Process (RUP) :
RUP is a software development process from Rational, a division of IBM. It divides
the development process into four distinct phases that each involve business
modeling, analysis and design, implementation, testing, and deployment.
RUP
|
• Iterations
|
• Phases
|
• Inception Phase
|
|
• Elaboration Phase
|
• Construction Phase
|
• Transition Phase
|
Agile:
Agile software development refers to a group of software development methodologies
based on iterative development, where requirements and solutions evolve through
collaboration between self-organizing cross-functional teams.
Agile
|
• Design
|
• Build
|
• Configure
|
|
• Test
|
• Release
|
|
Scrum:
Scrum is a specialized version of agile project management methodologies. Scrum
projects are characterized by a product backlog - a list of tasks that come up
while the sprint (a highly focused period where tasks are completed, generally
running 30 days) is underway. The idea behind Scrum is to create a streamlined
project management process that produces a quality end product.
Scrum
|
• Stories
|
• To Do
|
• In progress
|
|
• Testing
|
• Done
|
• Scrum Master
|
Design Patterns:
a software design pattern is a general, reusable solution to a commonly occurring
problem within a given context in software design. It is not a finished design
that can be transformed directly into source or machine code. It is a description
or template for how to solve a problem that can be used in many different
situations. Design patterns are formalized best practices that the programmer
can use to solve common problems when designing an application or system.
Creational Patterns
|
• Singleton
|
• Factory
|
• Factory Method
|
|
• Abstract Factory
|
• Builder
|
• Prototype
|
|
• Object Pool
|
|
|
Behavioral Patterns
|
• Chain of Responsibility
|
• Command
|
• Interpreter
|
|
• Iterator
|
• Mediator
|
• Memento
|
|
• Observer
|
• Strategy
|
• Template Method
|
|
• Visitor
|
• State
|
• Null Object
|
Structural Patterns
|
• Adapter
|
• Bridge
|
• Composite
|
|
• Decorator
|
• Flyweight
|
• Proxy
|
|
• Façade
|
• Private Class Data
|
|
Security:
We view security as levels of armors or shields and our thinking and approaches of Security Levels are as follows:
Security Levels
|
• Networks
|
• Software
|
• Architect-design
|
|
• Development
|
• Web Services
|
• Data
|
|
• Hardware
|
• Users
|
• Employees
|
Security Approach
|
• Sand Box Approach
|
• Secure classloader
|
• Bytecode Verifier
|
|
• Security Manager
|
• Cryptography
|
• Public Key Infrastructure
|
|
• Secure Communication
|
• Access Control
|
• Authentication
|
|
• Authentication
|
• Authorization
|
• Assurance
|
|
• Security Attributes
|
• Secure Sockets
|
• SSL Certificates
|
|
• Encryption
|
• Compression
|
• Firewalls
|
Infrastructure:
Infrastructure management and teams are responsible for architecting, building, managing
and maintaining the entire software (clusters, virtual and bare metal servers) infrastructure
and data centers. They work with Development, Testing, System Infrastructure, Sales
Infrastructure and the rest of institution's departments. They perform analysis, architecting,
documenting and tracking the building and the execution of the requested Infrastructures. They
create specs-docs. Infrastructure docs-specs must be approved. These Docs-specs are given to
offshore teams to build and test.
Web-App Servers
|
• Browser-Mobile
|
• External Interfaces
|
• Load Balancer
|
|
• Firewall
|
• Web
|
• Batch
|
|
• File
|
• NAS
|
• SAN
|
|
• Database Interface
|
• Database
|
• Bridge
|
|
• Internal Interface
|
• Products
|
• Application
|
|
• Vendor Software
|
• Operating System
|
• Documentation
|
Topology
|
• Star
|
• Mesh
|
• Ring
|
|
• Bus
|
• Tree
|
• Other
|
Network Specs
|
• Cluster
|
• Network
|
• Node
|
Shared Properties
|
• File transfer
|
• NDM
|
• External MQ
|
|
• SFTP
|
• Share CPU
|
• Share Memory
|
|
• Share IP address
|
• Hardwired
|
• Socket and buffer
|
|
• JNDI
|
• Load balancer
|
• Failover
|
|
• Web Services
|
• Database Pool
|
|
Session Communication
|
• Internal MQ
|
• External MQ
|
|
Communication and
|
• Socket and buffer
|
• UDP multicast
|
• TCP/IP
|
Failover Group
|
• Streams/Piping
|
• Cluster Messaging Protocols
|
• Peer-to-Peer
|
|
• Session Communication
|
• Lazy Communication
|
|
Space Specification
|
• Space Requirement
|
• Memory and Growth%
|
• File Storage and Growth%
|
|
• Disk Space and Growth%
|
|
|
Documentation
|
• Tech Requirement (TRD)
|
• Proof of Concept (POC)
|
• Change Request (CRQ)
|
|
• Growth Approval
|
• Service Level Agreement
|
• Capacity
|
|
• Timeline
|
|
|
Diagrams
|
• Topology
|
• Servers Layout
|
• Database Servers
|
|
• Interfaces
|
|
|
Resources
|
• Resource Requirements
|
• Monitoring Requirements
|
|
Budget
|
• Balance Sheet
|
• Budget
|
|
Permit
|
• Permit to Build
|
• Permit to Operate
|
|
DevOps:
DevOps (development and operations) is an enterprise software development phrase used to mean a type of agile relationship between development and IT operations. The goal of DevOps is to change and improve the relationship by advocating better communication and collaboration between these two business units.
We had architect our Intelligent DevOps Editor with "Turn Key" features requires that we must have a good handle on all the details of running infrastructure team (provider) and their clients. To have "Turn Key" features, we must address the needs of our editor end-users. "Turn Key" features would reduce if not eliminate any or all the interfaces between the infrastructure team and their clients. We leveraged Virtualization in building virtual networks. Check our Intelligent CRM Metadata page for our Intelligent DevOps Editor link:
Our Intelligent DevOps Editor - "Turn Key" Software
System Specs
|
• Distributed
|
• Geolocation
|
• Mobile
|
|
• Web
|
• Cloud
|
• Governance
|
|
• Multi-Node
|
• Batch
|
|
Communication
|
• Socket and buffer
|
• UDP multicast
|
• TCP/IP
|
|
• Streams/Piping
|
• Msg Protocols
|
• Peer-to-Peer
|
|
• Session Comm
|
• Lazy Comm
|
|
Plans
|
• Backup System
|
• Recovery Plans
|
• Monitoring
|
|
• Logging
|
|
|
Support
|
• Help Desk
|
• Legacy Buffer
|
• Monitoring
|
|
• Logging
|
|
|
Testing
|
• Testing Types
|
• Test Plans
|
• Built-in
|
|
• Automated
|
• Manual
|
|
Prototypes and Designing and Building Projects' Websites
We recommend that every project should have it own internal or external website
for presentation, sharing and documentation, reviews and critics feedback. The
site can also be the project prototype for teams, clients and stakeholders to
view the project and its progress.
Page Building
|
• Search Optimization
|
• Site goals
|
• Layout
|
|
• Target Audience
|
• Graphic Design
|
• Proof Reading
|
|
• Documentation
|
• FAQ
|
• Contact
|
|
• Maintenance
|
• Search Options
|
• Testing
|
|
• Hosting
|
• Security
|
|
|
|
|