SIMPLIFIED PROJECT MANAGEMENT TECHNIQUE: Introducing a super flexible project management methodology

Even though we all are well versed with the term “Project Management”, still you might have doubted what it exactly means and how it becomes a beneficial tool when it comes to manage a given project.

Let’s define the thought in a more common way.

Project management is the art of handling the diminutive aspects and attributes of a client’s requirement(s) by one or more specialists in such a way that, the ultimate product(s)/service(s) delivered is the core resemblance of what the client envisions.

There have been numerous ways, how the existing players run this process. Most of them are expedient with the conventional scenarios and are solely depended on the contemporary paraphernalia and ideologies.

Even though these practices and procedures are highly appreciated in the past and wholly recognized in the present, the future demands high-end augmentations to get adjusted with the forthcoming transformations in client’s perception on receiving reputation and value for the services they render. There arises the necessity of an improvised version of the all these alluring project management tools and techniques consolidated into one; Simplified Project Management Technique [SPMT].

Simplified Project Management Technique [SPMT] is an abridged and minimalistic project management ideology which works through an RRD (Requirements Recording Document), where the entire project execution is centralized to a single point; requirements gathering, brainstorming, development and deployment are accomplished by recording the subsequent updations simultaneously in the RRD until the project closure session, thus attains optimal output.

Why SPMT? The question overheard lurid.

So, before get going, check out why this practice is imperative and what are the advantages it has over the prevailing methodologies.

• SPMT is super flexible; as it revolves around one core document and with the help of different phases involved which are agile, SPMT can be incorporated into all project genres
• It hasn’t been developed from any theoretical facets, virtuously a practical approach
• Obliging to both clients as well as the project team in multiple ways
• Can be practiced regardless of the size of the company/organization
• Reduce late night emergencies by proper pre-planning of tasks. Read more on Late Sitting Theory, A Major Threat For Productivity
• Moreover, an intermingling of classical and modern approach

That’s it. Now you can eavesdrop to your inner beat. It’s entirely your choice whether to check it out or not. If you are planning to see through it, keep reading. It won’t make you feel nosedive. Cheers!

This article extends one core idea of managing software projects which is an improvised version of the contemporary existing global project management ideologies. This is a six-step process. Let’s begin!

Phase I: Scope Definition

It all starts with a thought. Either it can be as modest as clicking a button or else as colossal as a live instant chat, like WhatsApp. The requirements array from rocket made to basic click and save. Here comes the role of a business analyst. He is the one who dives through the pool to seizure the thought process from the client and convert them into excellent basic project requirements. May be a Technical Lead also can contribute to this point; but it is the Business Analyst who owns this phase.

That’s how we define a Business Analyst; a corporate professional who possess the competence to convert the thought process of a prospective client into break even requirements in such a way that they form the building blocks of the entire final product(s)/service(s).

Business Analyst drafts Requirements Recording Document (which is RRD 1.0) and requests client for initial approval via emails, the essential tool for communicating with clients. The magnitude of email communication in the present scenario is inevitable. Read more on 7 Tips For Writing Smart Corporate Emails. The better you start focusing on those, the better you earn results.

It is very much evident that the initial requirements drafted by the Business Analyst will suffer multiple stretching and alterations on initial client review. After numerous brainstorming sessions with the client, incorporating the suggestions, client will waive the green flag to proceed further (which is RRD 2.0).

What does an RRD comprises of?

RRD, Requirements Recording Document is the core project documentation that the business analyst needs to record and revise on a consistent basis as the requirement and client recommendations changes as the project advances.

In a nutshell, this phase deals with: -

1. Analyzing and recording the client’s requirements on a business perspective
2. Multiple brainstorming session with the client side
3. Pilot study
4. Documenting the functional flow as an RRD 1.0
5. Getting consent and approval-RRD 2.0

Phase II: Subsequent Utility Handling

Subsequent Utility Handling and Scope Definition are two stages that can be worked out simultaneously.

Green signal for imagination and creativity blushes as soon as the client approves the RRD. The creative designer(s) works with the Business Analyst as well as the Team Lead to put up some exquisite designs that contests the client’s expectations. The designs will be either wire frame designs or original screen designs, depends on the level of requirement understanding.

At the same time, Business Analyst (with the support of Technical Lead) will update the RRD with the equivalent task split ups. BA will ponder every slight functionality, cross check the possibilities and make sure it enhances the final output positively. It is the Technical Lead who does the hours estimates with respect to the functionalities listed. Thus, a quality and workable project hour evolves; the High-level Estimate.

BA integrates the high-level estimates with the tasks split ups and incorporates them to the RRD.

After two or three recurring discussions with client with respect to the drafted project hours and created designs, finalization of the designs will be accomplished so as the updated RRD (which is RRD 3.0).

This segment will be the official closure point of project requirements for the first phase development. Whatever information passed, the suggestions approved, alterations consolidated will be considered as change requests, the surface line of the next level requirement gathering.

Even though client will have changes and alterations. As per SPMT, whatever new requirements, change requests, major suggestions (excluding any minor changes and enhancements) will not be entertained post closure of Subsequent Utility Handling phase.

In a nutshell, this phase covers: -

1. Drafting projects hours, preparing a high-level estimate and execution timeline
2. Drawing graphical and UX design flows, patterns or screens
3. Integration of the above to RRD
4. Client review and confirmation of RRD 3.0

Phase III: Win-Win Approach

This is where the cost factor comes in. The BA/Project Manager will estimate a commercial quote for the project with the help of RRD 3.0. This is the phase where the financial matters get settled and the boundaries are drawn. A sensible manager will always have that acquaintance to see through it. Read more on What Great Managers Do Differently

Cost will be estimated and presented in terms of client’s currency denomination and updated-RRD 4.0.

A win-win approach is put forward by both the client and the vendor to make sure the benefits are equally shared in terms of quality and monetary returns.

The updated RRD (which is RRD 4.0) will be presented to the client as “The Official Proposal” with the estimated cost split up and terms and conditions includes post maintenance.

If this phase is performed appropriately, it lays the foundation of a systematic project management. The best handled win-win approach, the finest project execution will be.

In a nutshell, this phase covers: -

1. Submission of Official Proposal Document
2. Discussions with the client on estimated cost
3. Finalization and getting approval from the client

Phase IV: Winding the Clock

Before win-win approach, before subsequent utility handling, this phase functions parallely. Winding the Clock is the input to the RRD versions via the internal brainstorming session conducted with in the team during the requirements analysis, functionalities and tasks split ups and effort estimation activities.

Without any difference, from junior trainee to the Project Manager, the involvement is strictly advised. You will never know who will come up with that mind-blowing idea which can amplify the entire development phase.

In a nutshell, this phase covers: -

1. Exclusive sideline internal technical discussions and meetings

Phase V: Development

This is pure development phase. The technical team will be well versed with all the functionalities and risk factors involved in the requirement set, as they were parallelly involved in the requirements study from the initial stages itself. Everyone in the development team is supposed to be in a position where every minute functionalities are clearly understood.

Coding starts and ends here. The involvement of QA-Testing team is well served in this phase. The milestones will be released, gets evaluated by the QA and then to the client. Continuous feedback will be shared by the client of each module to make sure the product is attaining the dream picture.

Eventually, after the completion of every milestone, the product will be released for User Acceptance Testing.

Any new recommendations/suggestions from client will be recorded (RRD 5.0) since the first internal release to the final UAT release. Minor updates and changes will be integrated parallelly (provided if it doesn’t affect the timeline so hard) to the current product version itself, any major changes/suggestions will only be taken care of after the UAT of the first version.

In a nutshell, this phase covers: -

1. Start and end of development/coding
2. QA Testing and client intern releases
3. Milestone winning
4. UAT Release

Phase VI: Mutual Handshake

This is the final phase; the project closure session. It is the responsibility of both the client and the project team to verify the most updated RRD which is RRD 5.0 and make sure that all the discussed functionalities are well included cleanly and perfectly included. After the verification by the client side, the product will be deployed to the production environment.

After the deployment, the client is entitled to sign the PCD-Project Closeout Document which will be finalized updated version of RRD (which is RRD 6.0) within 7 days starting the deployment success date. Also the original source code is handed over to the respective end points.

What is Project Closeout Document (RRD 6.0)?

PCOD is the conversion of RRD 5.0 in such a way that a new section will be added at the end of document saying that all the above requirements have been completed by the development team well and good, which is drafted in the company letter head. This document becomes valid only when the client puts his signature and seal/thumbprint. This document is optional and used only on specific request by any of the sides.

A mutually agreed period (noted in the RRD 6.0), the product will be monitored to make sure its effective interaction with the open environment. This concludes the whole process.

In a nutshell, this phase covers: -

1. Production Deployment
2. Signing RRD 6.0 by client
3. Source Code Hand Over
4. Project Closeout and Post maintenance

Minimal human resource requirements of performing SPMT are as follows:-

1. A Business Analyst/Project Manager/Client Manager
2. A Technical Team Lead/Senior Software Engineer
3. A Software Engineer
4. A QA Analyst
5. A Graphic Designer

RRD Basic version-Table of Contents: The suggested headers that can be included in the table of contents of an RRD document are as follows:-

1. About the document (document header)
2. Project Approval Agreement (enclosure)
3. Introduction (document header)
4. Memorandum of Requirements (recorded with date and estimated hours)(document header)
5. Project Timeline (document header)
6. Commercial Quotation with costs split ups (document header)
7. Human Capital Note (document header)(optional)
8. Software Requirements Specifications (document header)
9. Release Plan (document header)
10. Risk factors involved (document header)
11. Terms and Conditions (document header)
12. Change Requests (with recorded date and estimated hours)(document header)
13. Project Closure Agreement (enclosure)
14. Conclusion (document header)
15. Appendix A — Glossary of Terms (document header)

You might have wondered how these common attributes produce positive outcomes when combined. But if you trust the process and execute the steps systematically, you can witness the glorified outcome.

That’s it. Heads up guys! Now it’s time to improvise your thought process and manage your projects more effectively. Let the essence get shared by both sides; the best practice to nurture and implement in the ever-changing project management arena.

Now it’s time for you to grab the simplest of thoughts; it’s all yours! Thank You.

Disclaimer: This concludes the elucidation of SPMT which is virtuously developed on the relevant practical feedback from a sample lot of some prospective players in the IT industry. The author doesn’t claim any optimistic upshot on the same upon implementation. It merely depends on the speculative attributes such as nature of the project, associated human resources and behavioral pattern of prospective clients.

Click here to read more articles from this author

Cheers!

akhi_official