World Class Project Management
Agile or Waterfall, we’ve been managing SDLC IT projects across a multitude of government and blue-chip clients for many years.
We always tailor our proven project management approach to fit your business culture and budget. Our projects are well defined and designed to run smooth, fast and very efficiently, so you get the best value for money.
Having the best developers is only one part of our success, having world-class Technical Project Management and Business Analysis skills guarantees you successful results.
Methodologies
Agile
We are well known for extremely fast delivery of work items. We attribute this strength to working within an ‘Agile’ model, that we have streamlined further. We buck the trend a lot by having daily technical scrums and very short sprints in order to keep a steady stream of improvements being received by our clients. Our clients are engaged very early in the development process and share in the excitement of a new solution every step of the way to completion.
Waterfall
We are very experienced with delivering results within a traditional ‘waterfall’ model. While we prefer the Agile model for iterative development and speed, the waterfall model is still used in many of our clients and we adjust our approach to fit.
Success is about Approach. Here’s how we do it.
On-Time Delivery.
- Define the Job in Detail.
- Review project environment.
- Organize by major business function.
- Identify products to be delivered.
- Document IT/user responsibilities
- Create “system test plan”
Involve the Right People.
- Identify project personnel.
- Structure Project Responsibilities.
- Establish roles, goals and objectives.
- Subcontract Project Teams.
- Create “winning environment.”
Estimate Time & Costs.
- Avoid “premature cost precision.”
- Include everything in your estimate.
- Estimate both elapsed time and dollars.
- Document estimating assumptions.
- Establish “budget for change.”
Break the Job Down
- Define all tasks in “80 Hours” or less.
- Translate estimate into products.
- Identify each “80 Hours” into deliverables.
- Obtain individual product commitment.
- Create “weekly status reporting.”
Set up Change Procedure.
- Define procedure for changes.
- Document all scope changes.
- Determine impact of changes.
- Obtain budget/time authorization.
- Agree to “manage changes.”
Agree on Acceptance Criteria.
- Formally agree on acceptance criteria.
- Document the series of approvals.
- Identify appropriate personnel.
- Establish key authorization to proceed.
- Agree/deliver/approve = “DONE.”
SOA vs API
This comparison keeps coming up so here are 6 points to keep in minds when assessing the similarities or differences between APIs and SOA and choosing an API Management solution:
- While APIs are generally associated with REST/JSON and SOA is associated with XML and SOAP, SOA is more than just a protocol. SOA stands for “Service Oriented Architecture” and is an architectural best practice around building de-coupled applications and fosters service re-use. The API Economy is also all about creating services and making them available in an open fashion.
- APIs can be used for both external and internal use-cases. The key difference between APIs and SOA being that APIs are more open, well documented and can be often self-provisioned, with little or no guidance, making them better suited for mass developer/partner consumption. SOA or XML services are pre-dominantly used for internal use-cases, though they are prevalent in a number of external B2B scenarios.
- While APIs are currently associated with REST and JSON, there are other protocols like web-sockets, MQTT etc. that are gaining prominence for specific use-cases. Just as SOAP has it merits and limitations, REST will be replaced by something else. API providers should look at deploying API Management platforms that future proof (and past-proof with SOA support) their deployment with an unified infrastructure, rather than taking a tiered approach. You do not want to deploy another tiered infrastructure once another protocol surfaces
- Both APIs and SOA services have to be secured, monitored, orchestrated, mediated and audited. These operational aspects of APIs and Services are often not associated with the respective message protocols, but are characteristics of the specific business service or operation they represent. In the services parlance, the common terminology applied to these operations is Policies. You should look at deploying a unified policy management across all your services, irrespective of the protocol they are tied to, in this case whether they are APIs or SOA.
- API and SOA are both services. They depend on other application and services, which are often managed by other developers, organizations and even completely different providers. Changes to these dependent services need to be managed and governed, as they could impact your API for SOA services. The architectural principles around security, compliance, policy management, monitoring and analytics are same or similar.
- Both API and SOA services have a lifecycle, which spans beyond just versioning. You need to manage how they are planned, have tools that support the development cycle and integrated your SDLC tools, can be migrated with from different environments (ie from dev. to stage to production) and can be retired without adversely impacting your or your customers’ business.
So while APIs have their own unique characteristics, at the core they are not that different from SOA and enterprises should try to use a common infrastructure to manage and govern the commonalities between them, rather than deploying redundant or “tiered” infrastructure.
PMI Accredited
PMI is the world’s leading membership association for the project management profession, with more than half a million members and credential holders in more than 185 countries. We use many of these principles and more in the running of our projects.
