Every technology adoption in a business is seen to be on the positive side of its ROI. ROI includes tangible and non-tangible gains, both. There are various factors kept in mind by any business planning to adopt any, two of them, or all the three technologies to enhance their business. Few core factors can be taken into account are being discussed below.
Lower Capital and Operational Cost might not hold good in all adoptions as initial adoption of any new technology required both but it can be well balanced with the projected returns.
Innovation: These technologies require lot of innovation and ideas to establish. New paths need to be invented to acquire more customers, create customer delight and build larger volume of prospects.
Simplification of Processes: Core business processes take a steep change with adoption of these technologies.
Role of HR: HR has to play a major role in mobile and social technologies adoption. They become the strategic partners in a big way for these two technologies adoption in the organization.
Transformation: It demands a major change in functioning and processes of the business.
Evaluation and Assessment: A continuous evaluation and assessment process has to be in place while and post adoption of these technologies. There has to be a process to get feedback from customer and other stakeholders to ascertain the value gained.
Recruitment: Acquiring altogether different employees expert in these technologies to give it a thrust in adoption and fetching results out of it.
Security: Last but not the least, the most important factor – Security, needs to be handled and managed in an entirely different fashion in these scenarios.
Technology advancement is a continuous process. The three major technologies that have revolutionized the current decade are Social, Mobile and Cloud technologies which have impacted businesses in a very big way. There is no business these days which is untouched by the heat of these three technologies. Some businesses especially the large ones and those which are conscious about their outreach to last mile of consumers/ users have already taken the lead and taken initiatives to deploy it and delve into it in a larger manner.
Getting into any technology requires a structured planning and methodology. Without a proper planning or going into it without an organized manner can rather lead any business into a negative mode. There need to be appropriate policies and procedures in place along with a large amount of brainstorming to move ahead in adopting any or all of these technologies. All three technologies play a major role not only within the organization but in the outside world also among all stakeholders – be it prospective customers/ employees /.partners, or existing ones. For example regarding the security of information has to be taken care in a broader way to cater to multiple platforms, multiple devices and other needs.
These technologies are definitely making a big positive impact on the business provided these are handled with care. The investment in these technologies has also to be worked out in a sensible manner by taking care of various options available in the market otherwise a big investment might result into no end results.
Quality is a lot more that identifying and controlling defects. With increasing dependencies on business applications be it on server, mobile or web; is demanding more and more professionals who are capable of this paradigm shift and are intelligent enough to accept the challenge. One of the major areas to be focused in Quality is about understanding of existing processes and efforts towards their enhancements and optimizations.
Business software application is a basic requirement of any business these days. Businesses are emphasizing more on automation, consolidation and integration. Innovation and improvement is always welcomed in this field. With the exponential increase in software industry in the global arena, emphasis on quality needs, its optimization and adherence to processes is becoming more and more important.
The software industry is growing steadily with clear cut demarcation of boundaries. The applications are being built keeping in mind to cater to global market rather than the local area. Because of this fast growth in software industry, there is an increasing demand of quality professionals which will keep increasing in coming years.
There is a huge shift in mindset regarding scope of quality in software industry. Given the fact that dependency of business is increasing on applications, the adverse impact of any flaw bypassed during quality might impact business heavily. A small transaction leading to a wrong calculation due to a bug could cost a high amount to the business. Quality therefore has a higher amount of significance in today’s scenario.
Development process is supposed to ensure complete adherence to customer requirements and business alignment thereby making it useful for customer else there remains a never ending fight between the customer and delivery organizations regarding the gaps left un-addressed. Even if there is some gaps remain in the final deliverable and those ‘asked for’; it should be closed at the earliest with mutual consent. This can happen only when the development team gives some valid reasons for not filling those gaps due to what so ever constraints and customer agrees to it. Hence due to this higher stake of correctness of coding adhering to customer requirements, it becomes very important for quality to pitch in and ensure a zero defect product.
There has to be a good balance between coding and testing throughout the development cycle. For this, a tester’s knowledge about requirements and product in questions is as critical as it is for development team.
Software industry depends highly on quality of product. Bug encountered during and post production but before launch always cost in terms of time and money. Fixing a bug might take a small chunk of time but retesting again is a time consuming job which is required to ensure the impact of bug fixed should not degrade or put a negative impact elsewhere in functionality or business process. Quality again has to play a major role but the onus lies on development team also to ensure a bug free ‘bug fixing’.
Three important acts to perform during product development in a continuous manner can be listed as below:
1. Reviewing Process: Regular reviews, on one hand are quite important; and on the other hand, it is also important to keep reviewing the processes defined for development and testing of a product. The team, process and timelines need to be aligned tightly so as to ensure no leakages during development or after the release of product.
2. Customer Requirements: It is not a one-time exercise to capture customer requirements and then start development in closed doors. This will always lead to failures and disasters in the short and long term, both. It is very important to keep customer engaged during every iteration, internal releases, and milestones completions.
3. Best Practices: How so ever best your practices may be as per your claims, but there is always a scope of improvement, without any doubt.
Typically the vast scope of quality can be divided into three major streams – Quality Control (QC), Quality Assurance (QA) and Compliance. All three streams are critical for any organization engaged in software development activities – be it as a vendor or for internal use. In any case – an internal development team of an organization also more or less is like a vendor which has to ensure smooth delivery and functioning of the products they develop and deploy within their organization.
Scope of Quality Control (QC) is limited to product’s handling, testing, reliability, stability, bug finding, maintaining testing reports and ensuring compliance of documents required for the purpose of audits. QC is responsible for inspection of the product in all aspects from user and business perspective. Code testing and testing of product for the purpose of finding bugs, reporting, maintaining data and its history, getting bugs fixed, retesting, and ensuring finally that the product goes for release with no bugs or leakages. Test cases, test specifications and testing are very important. Retesting of product post fixing of bugs by development team is as critical and needs to be as exhaustive as first time testing of the product.
Scope of Quality Assurance (QA) is to ensure keep evolving best practices, ensure its compliance and adherence with continuous effort to uplift quality standards of the organization and teams by means of training, documentation, audits and change control mechanism. QA is required to be focused more towards compliance and adherence of processes in place. A re-assessment of processes in place is required to be done from time to time. External certification of global standard and regular audits by them always helps in this respect.
A wireframe is nothing but a blueprint for any sized software project in today’s corporate world. Think about a building on a land is first presented as a blueprint in order to explain the architecture and design of that building. The layout of the building is shown on this blueprint along with the components to be used for designing of this building. In a similar manner a wifreframe is an introspection of a software application in a layer by layer manner so that the application in question can be viewed/ reviewed from different angles.
A wireframe is a powerful tool to present a software application design and architecture in a crisp and clear way that enables you to understand it much strongly. An application can be referred to any business application, mobile application or website portal. A wireframe presents a 2 dimensional picture of your application in order to understand it more deeply and from different perspective.
A wireframe provides a visual map of your complete application so as to help you in see the application flow, navigation, correlation of various components of the application, linkages and associations. An application that is first presented through wireframe gives you a confidence about its flawless design, navigation and ease of use once you go through it and find out the gaps. A wireframe helps you to find out these gaps well in advance and hence assists you in completing your projects well in time with least amount of risks.
PMI – Project Management Institute is a global membership organization for professionals in project management. It announced that the prestigious Eric Jenett Project Management Excellence Award for 2013 regularly organized by PMI goes to ESI International Executive VP J. LeRoy Ward, PMP, PgMP, CSM. The award is presented to an individual professional every year by PMI for contributing outstandingly to the practices of project management by means of demonstrating initiatives and leadership style in a unique manner so as to enhance PM techniques, concepts, practices or theories that are widely acceptable and applicable.
Ward, while accepting this prestigious award, added to his speech that he is feeling highly honored to get this award. This way he has been added to the list of past honorable winners of this award who have been acknowledged for their passionate work towards project management excellence and innovation. Ward has more that 38 years of experience in project management, program management and portfolio management in the U.S. government and various private sectors. He is known for writing various highly acclaimed books on the subject and is a well known speaker at global conferences.
5 Ancient Principles Of Leadership is a lovely read that you will enjoy for three reasons – it is crisp, it is short and it gives you a lot to learn. As a project manager this book written by Jack Myrick has some basic fundamental principles to teach you that if you employ in your professional life, will never let you down in terms of meeting your targets or managing your teams. This 87 pages book has been published by Jaico Publishing House and it is a fable of a ship builder.
Rule 1: Make Them Appreciated: Your team members are as important as you are for your organization. As a child needs pampering and feels happy about it, similarly your team members need to be appreciated. Appreciation gives a feeling of achievement, satisfaction and motivates one towards his goals.
Rule 2: See Their Potential, Not Their Flaws: Instead of keep cribbing about what not has been done, it is better to understand what each of your team member is best in and then give him/ her tasks according to their potential. Putting a person with perfection in one field put on to achieve success in another field might end up in a failure.
Rule 3: Lead With Authority, Not Power: Use of power generates revolts but using authority demonstrates a great leadership skill.
Rule 4: Love Them First: Before you assign them a task or wait for them to complete a task, it is important to make them feel that they are being loved whoever and whatever they are. Once the message is clear, it may lead to wonderful results.
Rule 5: Make Them Feel They Are Part Of Something Special
No. 1: If you are clear about your destination, it becomes easier for you to decide about your journey.
No. 2: Drawing out productivity is an art that a project manager and a team leader need to learn as soon as possible as it is their sole responsibility.
No. 3: No business can survive without existence of its customers.
No. 4: In business it is not only a single person’s money that is involved, it involves money of various stakeholders.
No. 5: Any work that is done in a systematic manner will definitely fetch out some useful results.
No. 6: In absence of a plan there can not be any commitment but only promises and hopes.
Following 5 quotes are the best among a lot of 100 odd quotes I found.
Absolutely true. A code, a deployment, a training, a business analysis – everything has a optimum timeline.
Excellent quote. It is easier to demonstrate as a busy entity but the current scenario of professionalism doesn’t accept it if there is no visible result to the effort being done.
A warm welcome to Igor Ješe to accept my invite for an interview. He is the author of popular mockup tool MockupScreens. Recently Igor has published an easy and straight-forward generator of real-looking test and sample data named as MockupData. MockupScreens was built in 2003 by Igor as a simple tool to use it for himself and a small group of analysts. Within two years it was a well known tool to professionals outside his known groups.
Please tell about your early school days?
That really brings old memories, let me see. I barely remember my school days before I was 10 years old, it’s almost like I was just a bystander in my own life before that age. Then something happened and I started to fight for myself, becoming pretty stubborn in the process. Being a parent myself now, I think I can really imagine the hard time my parents had from one incident to the next during those years.
What were your plans during your later education days?
The weird thing is that I was by far most talented for physics, of all things. But when the time came to choose my professional education, I couldn’t for the life of me visualize myself as a physicist. So I went with my second choice, which was Computer Science at Zagreb University.
Circumstances quickly changed though, and I had to support myself for almost the whole duration (that dragged out to embarrassing 7 years, to be frank) of my studies. So when my Master’s Degree came in 1999, I was already employed with IBM for years and my course was firmly set.
What expertise did you achieve during your college days?
I guess I was lucky back then: I was involved in one of the biggest IBM projects in the region at a time. For a quick-learning and determined youth like me back then, it really seemed like a vast fountain of knowledge and experience and a playground with wonderful sci-fi technologies I’ve seen only in the movies before that. I came out with more than working knowledge of DB2 and WinNT servers, so I guess I got more than unfair advantage over my fellow students in the process.
What career did you opt to start with after completing your studies?
For few years, I was quite happy improving my skills as a database guy in development teams. But soon I started to feel “left out” somehow, it was like important things were happening somewhere else. So I started to steer my career towards Software Requirements, because I decided that was in fact were the operative decisions were really being made.
Since how long are your engaged in Software Requirements and Development Methodologies?
Software Requirements came as an intentional career move, somewhere before 2000. But the genuine interest for Development Methodologies started in quite different manner. In 2001 several colleagues and myself joined the small high-tech company in the making.
But within months we were all pulling 60-hour weeks without any real idea how we got ourselves into that mess. So we as a group decided there must be a way to work smarter instead of harder, and busied ourselves with UML first, which quickly led among other things to RUP and formal Project Management.
After several years of testing and customizing heavily all the knowledge we could find for our own practical day-to-day use, the results were so obvious that other companies started to hire the whole bunch of us as “methodology consultants”, to do the same for them.
What is the tool that you have developed? It is meant for whom? What purpose does it suffice?
MockupData (www.MockupData.com) is a data generator, the tagline I settled on is “Make your data look real”. Basically it generates bulk data that looks like a real thing: real-looking names, addresses, etc. Software testers use it to populate the applications they need to test.
There is no realistic testing having the fields of your system filled with random strings and numbers that human being cannot relate to anything from the real world. And populating databases with “almost real” data in realistic quantity is either prohibitively expensive in human effort or simply not feasible – e.g. because of data privacy regulations.
How did you conceive the idea to develop this tool?
Actually I have needed something like this myself many times. Several times I have even implemented something similar for a specific project and specific database. And in 2003 I have even published a precursor to MockupData, as a joint effort with a friend. But we were quite inexperienced so the partnership hasn’t worked out, which was nobody’s fault really, but the product just faded out before it got any real traction on the market.
Occasionally I have used this first product for my own purposes afterwards, and it simply felt a shame that I couldn’t offer it to other people. So I finally started from scratch and MockupData is a result. With which I’m very satisfied I must say, and the early feedback is simply fabulous. Testers and database developers need something like this, to create and re-create quickly and at will different variations of real-looking data, and in thousands or even millions of records when needed.
How much time did it take to develop this tool and with what size of team?
More than a year with three people putting approximately half of their time into it. Which was quite longer than I anticipated. I thought that since I exactly new what we needed to implement it would be a fairly quick project. The core “engine” took only a few weeks. The whole tool only several months. So far so good.
But then we came to usability. We had many concrete ideas how to make ordinary tasks more smooth for the user but no ready-made support for them in wxPython, the GUI package we were using. Finally I hired a usability designer to help us out, a great Spanish guy that on and off spent months discussing with us different ways to implement most of those ideas, and then to test and re-test and tweak everything.
What is the development methodology you adopted to develop this tool?
I knew you would ask that and still I don’t have a ready answer for you Frankly it was a mix of best practices: implementing small fixed chunks at a time, tricky parts first, stopping for refactoring when needed, while continuously having a “clickable build” and continuously unit-testing everything except the GUI.
I believe in creating a team of great people and letting them work, and to tweak methodology to suit them instead of the other way around. Most techniques in any methodology are in fact trade-offs, and if something doesn’t work for your particular team and your particular situation – out the window it goes.
What so ever is the fate of a project, it has a long lasting impacts at various levels and in various directions. If a project fails, it impacts your market value and reputation. It also impacts on your relationships with the customer for whom this project was being done. Then there is adverse impacts that automatically seep in inside the organization. The teams that were engaged in the project morally start owning this failure and unknowingly a feeling of guilt resides inside their heart. That itself becomes a demoralizing factor for forthcoming projects.
Then it is between various stakeholders and the management who stop seeing each other eye to eye. A failure of a project also becomes a blot on the performance of project manager. Hence overall a single project’s failure has multidimensional and multi-intensity impacts. For customer it becomes multiple loss. When a project fails, customer loses money, time, and fulfillment of a dream. It hurts customer and probably that becomes the reason of getting a negative reputation spread in the market through word of mouth of customer. All this has a recursive effect on the overall health of the organization. Multiple because the running project that failed during its final stages resulting into loss of money, time, resources, reputation etc.; and due to this loss your forthcoming business gets impacted hitting you with a double sided sword.
On the other hand success of a project results into compounded success. Your satisfied customer brings in more customers, your successful completion of project scales up your market reputation, your internal atmosphere becomes inspiring and teams get motivated to handle next level of hurdles.
When a project is assigned to a project manager, his first and foremost intention must be to chalk out a strategy to ensure timely completion of project without any compromise with the quality and financials. Most important for a project manager is to review Business Case once again so as to understand it thoroughly and an extra bonding with the project is built that becomes an additional driving force to act as a catalyst to the progress of project throughout its lifecycle. Some clear cut derivatives need to be worked out from the Business Case.
A project as such is both for a project manager – a problem and an opportunity as well. Problem because someone (customer in this case) wants a business solution to streamline their processes and hence that requirement needs to be catered to as per committed timelines and scope. Opportunity because once you decide to solve an issue for a customer (here in this case is to built an application in accordance to the business requirement specified) that resides at one level, you equip yourself to climb up to next ladder to handle higher level of issues and business requirements. That is how a project leader becomes project manager. That is how a person who is a team member once, becomes project owner and gradually reaches to a level where he or she handles multiple projects at the same time with complete attention, energy and dedication to each.
Business benefits to customer must be very clear right since beginning of this project which should start coming into light by the end of project.
Project Initiation: Every project has these basic phases during its lifecycle – Project Initiation, Project Planning, Project Execution and Project Closure. Each of these phases consist of a number of activities basis which success (or failure) of a project is ascertained. In project Initiation phase – when a project is borne, Project Definition is documented. Once project definition gets signed off, this project gets assigned to one of the project managers. This completes the Initiation phase.
Project Planning: Next comes the Project Planning phase. This phase begins with a very important task of requirement gathering, requirement analysis and definition of scope. Basis Scope Definition, Work Breakdown Structure (WBS) is made. WBS is a task wise breakdown of major milestones/ releases defined. Based on WBS, activities are defined and their hierarchy/ sequencing is set along with their timelines estimations. These activities are then scheduled for their respective releases by allocating appropriate resources and budgets with them. Identification of appropriate resources and right estimation of budgets is one of the key thing in this gamut.
Project Execution Phase: This phase is the real war game of the complete project. In this phase we execute, monitor and manage the overall WBS with ascertained milestones keeping in mind to mitigate any risks to ensure adherence to timelines, quality, and project closure as per plan.
Project Closing: The final stage of project management lifecycle is Project Closure where the project gets signed off
High Expectations Are The Key To Everything by Michael Bergdahl is a fantastic self booster and motivational guide. Michael worked at Walmart Headquarters in Bentonville, Arkansas, as Director of “People” and was reporting directly to the Founder of Walmart, Sam Walton. Sam Walton has been a big inspiration in Michael’s life and has influenced him in many ways. Michael is known to possess an authority over the best practices of Walmart and Sam Walton. Currently Michael is a Professional International Speaker and has visited to many countries across the globe. He is engaged with many big global corporate. Michael says to for writing High Expectations Are The Key To Everything, his main source of ideas, insights and inspiration has been Sheryl Bergdahl, his wife.
As per Michael it is nobody else that stops us to set higher standards and achieve higher in life, but ourselves. Challenges are there in everybody’s life. Some build courage to cross all hurdles and achieve success whereas others get discouraged by the obstacles in their life and get drifted away from success even if both start with same resources and get same opportunities. There are total 6 keys to success described in this book by Michael by setting higher expectations from yourself to get all round success. You need to set your vision and purpose with a commitment to yourself to move to your goals with passion.
Next key is – you can control your own destiny and achieve success in life but with some gem like mantras – having focused and disciplined approach towards your goals, hard rock determination, and you will have to sacrifice something in your life to achieve something much bigger; with an ability to adopt change with the changing environment.
Overall this is a must read for anyone aspiring for following a tougher path to achieve big results in life.
It is not easy to drive a project being a project manager when you have multiple projects in hand. You really need to have a concrete strategy, plan and process in place to make it a win-win situation for all stakeholders. Every stakeholder’s eyes remain on you to manage and monitor your project and you need to have a proactive approach to assess any stipulated (or unalarmed risks that usually happens) and raise an alarm to mitigate the risks in time without compromising with costs, timelines, process, product and quality.
To understand basic things first, your project’s life starts with project definition, project scope and then project requirements. All the three elements need to be taken care of in a very crisp and elaborative manner so as to get a clear cut sign off and to avoid any ambiguities that might occur at a later stage. Project requirements need to be scrutinized and understood well so as to build work breakdown structure (WBS), basis which you will be preparing your team’s activities and tasks with appropriate timelines of releases, estimations, resource allocation & management, and costing involved.
If you have been able to perform your job well up to this stage, be assured that you have scripted half of the success of your project already. Based on what you have prepared as listed above, it becomes easier for you and your team managers to monitor and control with least chances of failures in adhering to your estimates and plans.
Book Review: Improving Your Project Management Skills by Larry Richman: Enriching Project Management Skills
Improving Your Project Management Skills by Larry Richman is a really enriching book for all aspirant and established project managers hungry for getting mastered in enhancement of their skill for managing projects. The second edition was published in 2012 and is themed on one of the most popular seminars with the same name in the United States conducted by American Management Association. The second addition has been completely aligned with PMI’s PMBoK (Project Management Body of Knowledge ®) in terms of revised Project Management Standards, Practices and Methodologies.
This excellently presented book completely covers a project’s lifecycle right from its inception to project sign off. You will find a comprehensive coverage of step by step process knowledge of real life projects. The life of any project begins documentation of project definition, project scope and project requirements; and their subsequent sign off to kick start a project. Once the project initiation is handled in a structured manner, there remain less chances of hiccups in its execution and deployment in the next stages.
On the basis of project requirements are captured in detail, what a project manager needs to do next is to build work breakdown structure (WBS). The same can be translated to diagrammatic form to manage the sequential activities of project execution/ development phase. Basis work breakdown structure, tasks’ estimations are worked out for each activity with appropriate timelines, team estimations, resource management and financials.
Improving Your Project Management Skills by Larry Richman, in a nutshell helps you in chalking out concrete path to accurate estimations and execution without getting budged off with your timelines, costs, resources, quality and teams.
Generally three key factors are considered to work out on future of any running or starting project and those are – Cost, Time and Quality. It is assumed that if these three factors are monitored closely throughout the project lifecycle, a project manager can easily predict the future of a project. In real life practice and especially for large sized projects these three dimensions do not suffice the process of proper analysis for the purpose. There is a fourth dimension that needs to be added to it and that is ‘scope’. This is an entity that can contribute to a large extent in shambling your targets of cost, time and quality.
Scope is something that needs to be finalized and controlled throughout the project. It does not mean that you are not entitled to change scope during a project. Of course if there is a change in business scenario of the customer and that required a change in logic or flow of the system, scope chance can’t be entertained. There is a fifth dimension that is a complex one to handle almost to the same extent as that of ‘scope’ that impacts heavily on progress and success of a project as per desired pace and that can be termed as ‘team’. Team size/ composition is one sub dimension of the dimension titled as ‘team’ and another sub dimension to this is team members turnover.
We all are aware that in current days tight conditions we can’t have backup for each member but definitely project manager need to have a concrete alternatives in mind so as to have a quick remedial action if any of the dimension in going to impact on project’s projected timelines.
Shorter projects do need lesser attention as the iterations are quick, with shorter timelines of deliverables and milestones. In a short duration if a milestone gets missed, it raises many eyebrows and things get controlled in a fast manner. It is reverse in case of longer duration projects. In longer duration projects, milestones and deliverables are not too close and hence chances of focus getting drifted away are higher. If, for example, the duration of project is more than a couple of years and major milestones are scattered over an average of 3-6 months, it is difficult to get senior management’s engagement in the project in a tightly woven manner. It might happen that senior management does not discuss about this project for a couple of months if there are no major milestones visible during that period.
PMO or project board in this case, like senior management, might oversight such projects, keeping in mind that they have a number of projects in their kitty, including some major and critical short term projects. This acts as a double sided sword creating twofold risk. One, the sleeping volcano has a chance to get blown any moment of time. Second, whatever discrepancies are found at a later stage (because of delayed reviews and management/ PMO ignorance/ lenience), it will not be less than a postmortem rather than a proactive approach to mitigate risks.
This in turn will be create havoc for the running project in terms of delays in timelines, overshooting budgets, frustration among teams, compromise with quality, customer dissatisfaction, and scope creep.
Enterprise Project Governance: A Guide to the Successful Management of Projects Across the Organization by Paul C Dinsmore and Luiz Rocha
This excellent book Enterprise Project Governance: A Guide to the Successful Management of Projects Across the Organization by Paul C Dinsmore and Luiz Rocha was released in 2012 that covers all major guidelines for handling large sized enterprise project. It also covers bottlenecks encountered during such project and how to mitigate those risks. Overall it contains 13 chapters taking you to a high maturity level step by step in management of governance of enterprise projects with least possibility of succumbing to failures. The journey starts with an elaborative but crisp introduction to enterprise project governance. It further delves down into the crux of governance of enterprise projects and how do you strategize it to make it a grand success. Next it takes to the risks involved in enterprise projects and how to mitigate the risk of uncertainty arising out of those risks. Portfolio management itself is a big thing in enterprise project and it is important to learn mapping of right portfolio with corresponding project.
Practicality of life begins in a project when you start making your strategies formed in the earlier stage into realities and thus start bundle of problems with that. There would be some pre conceived and anticipated problems but usually there are a separate set of problems that occur unalarmed and with no pre-notions. For that there needs to be a structured organization for managing projects along with appropriate management of stakeholders. It is also necessary to understand the role of the sponsor in enterprise projects. You get an insight on controlling and managing performance in order to avoid a situation where you start compromising with timelines, financials and/or the quality of deliverables/ milestones. There is a separate chapter exclusively covering very large sized project termed as mega projects. The same chapter also covers joint ventures and alliances engaged in enterprise project governance.
The last chapter covers challenges and roadblocks having a possible occurrence in all aspects and how to manage these challenges and roadblocks. Overall Enterprise Project Governance: A Guide to the Successful Management of Projects Across the Organization by Paul C Dinsmore and Luiz Rocha is a must read book for all project managers and stakeholders involved in Enterprise Project Governance. 271 pages of journey will end up with Sarbanes-Oxley Compliant Projects, notes and sources, glossary and abbreviations & acronyms thereby making your overall journey well enriched with various learning insights.
Basically Enterprise Project Governance is all about enterprise projects and their plan of execution with zero risk of failure. Governance is an integral part of tasks, activities, projects where different teams join hands to fulfill different modalities of those tasks, activities and projects. Governance is required to ensure completion of those tasks/ activities of projects within stipulated period of time, budget and quality committed and agreed upon among various stakeholders.
Large projects with higher volume of intricacies require higher level of governance with higher amount of seriousness. To execute large projects, there definitely need to be a structured and clearly defined approach which needs to be signed off by all concerned stakeholders. Timelines not only bind internal teams but the customer also is bound to adhere to timelines specified in project plan in order to benefit him at large.
At many places during different phases during project lifecycle, a project manager will have to take a detailed stock of situation so as to ascertain reorganization of plan in order to fill the gap between plan and actuals. A realignment might demand of extra efforts during such shuffles but that is important to do so as to ensure no delays in time and no compromise with the quality of deliverables.
The project approach that is defined and signed off at the start of a project has to be followed by each person involved in the project during the development and execution of a project. It is assumed that initiation phase meets its timelines most of the time and most of the hiccups arise during a project are either during development phase or its execution phase. Progress of a project is measured by means of objectively defined milestones, targets and releases defined with their timelines.
Any timeline anticipated in getting delayed to its execution needs to be alarmed as soon as comes into notice. Appropriate actions need to be taken so as to get the train back on track rather than wasting much time in postmortem of delays happened. Though analysis and in-depth probing is definitely a solid tool for learning of factors that caused delays and helping in future projects in controlling those factors, it can be done post release of major milestones or at a stage when the project is passing through happy state.
Ultimate goal of any project is to get what was planned during initial phases – in right shape, in right time, and of committed quality.
In today’s tough scenario of high competition, sinking economies and shrinking team sizes it is difficult to refuse management when there is a demand of high quality product without any compromise with the quality but at a lesser cost and a faster pace, it is not easy for a project manager to consistently deliver successful completion of projects with higher than demanded quality, lesser than stipulated budgets and lesser number of risks occurring during the entire project lifecycle? Getting success in one of many projects is not enough to impress anyone in the management. It is the hunger for regular success thereby inculcating as a habit that makes you star of the organization.
This definitely requires some courage to break the existing rules, redefining of existing processes and innovative techniques. It is really a challenging and uphill task for a project manager to attain this level of management where I becomes his habit to succeed in every project he has in his kitty. Under such circumstances a project manager needs to be proactive and innovative in his style of management of projects to such an extent that he is successfully able to get an instinct regarding any upcoming showstoppers thereby creating an innovative approach to realign project priorities, resources engaged in project and strategies formulated to organize project.
If you are a project manager in search of someone to push you or drive you, probably you are at a wrong foot of the ladder. The place where you are, as a project manager, have to ensure that your steering is in your own hands, you move in right direction, you move in right direction, and most importantly, you drive multiple vehicles besides driving your own, at the same time.
Well, that would be happening already, if you just look down to your regular exercise, the way you are driving your projects and teams. Good point is that you are already capable of driving yourself and others at the same time. Bad thing is that this art of driving yourself and others will get obsolete sooner or later unless you keep adding some value to it. Now, to add value to it, on a regular basis, you need to understand the factors (even minutest ones) that keep you motivated and boosted.
Some of these motivational factors in your life might not have ever been noticed by you, but you don’t afford them to go unnoticed for long, as these are your hidden treasures. And once you learn this art, don’t forget to download it to your aspirant team leaders, who shall be taking your place once you climb up the ladder.
Do you carry a traditional, orthodox style of leadership with your project teams or it has some unique kind of flavor in it with a different style of functioning, monitoring and appreciating your team members?
Usually most of the project managers keep on carrying on legacy style of leadership with no introspection, innovation and newness in it. Any leadership style that is static in nature will start stagnating in the longer run. A true leader need to have a dynamic style of leadership to handle his teams and project tasks based on person to person and task to task. Each person and task can’t be handled in same style. And as a matter of fact, being a project manager, you don’t need to put a needle on each and every task; and on each and every member of your various teams.
Let some of the accountability and responsibility be drilled down to team members and team leaders. After all, you know well, that you will climb the ladder soon, and will not stay project manager. Similarly your team members have to climb ladder to team leaders and team leaders have to become team managers.
To be a different kind of manager is not difficult if you keep your foot intact on ground all the time. Some basic things to keep in mind is that you have to be a good reader of personality of your team members with a good amount of HR quotient in it.
During the recently concluded Agile 2013 event in Nashville, besides other agendas, one prominent one was Agile 2013 Industry Analyst Panel Discussion. Panelists included:
- Thomas Murphy – Research Director, Gartner, Redmond, WA USA: Thomas Murphy’s top agenda is to ensure development and delivery of software in most efficient and effective manner. For that his spectrum keeps zooming around all phases of a project life-cycle starting from requirements analysis to development and testing to quality delivery to the end customer. He prefers to achieve his these goals by adopting collaborative techniques and agile practices. He focuses on alignment of an organization keeping pace with rapidly changing environmental factors impacting business. For that he vouches for more and more usage of mobile and could technologies. Thomas provides his expertise to IT chiefs of software development companies and thus carries a first hand experience of reality of life in these scenarios.
- Tom Grant, PhD – Senior Analyst Serving Application Development and DElivery Professionals, Forrester. Tom Grant takes care of guiding, grooming and mentoring organizations/ professionals engaged in development and delivery of applications. His strong forte is the areas of development and delivery of application that tackles with innovation processes. He has mastered the art of balancing Innovation, Agile, Product Management, Social Media, Product and Productionisation, application life-cycle management, business requirements and analysis, and embedded software.
- Melinda-Carol Ballou – Program Director, Application Life-Cycle Management & Executive Strategies, IDC: Melinda Ballou manages thought leadership, research and analysis via exhaustive research on application life cycle management (ALM). Her main focus remains on software life cycle – where she goes in depth of each and every processes followed and the way those are managed. Her other agendas include software quality and software governance. She provides her expertise via consulting to organizations engaged in delivering applications or which are having large in-house setups.
- Chris Rommel – Embedded Systems Practice Leader – VDC.
Agenda: The agenda of this panel discussion was to explore latest trends across the globe being followed and what are the best practices that are emerging out of it for Agile Software Development.
Here is the link to the Panel Discussion: http://www.agilealliance.org/resources/learning-center/event-agile2013-industry-analyst-panel-discussion
1. Study carefully all relevant documents handed over to you while assigning you your new role.
2. Don’t feel hurt when you are being told about so many problems regarding customers, teams, tasks, project etc., the moment you walk in the office. It is fine as long as you are aware about these issues beforehand and have already assigned people on this or have taken up in your task list.
3. A number of guys would like giving you advice on how to manage certain things or the new portfolio you have taken up. As long as you are cool in listening to their advice and are confident on how you will be managing your show in your own way – nothing to worry.
4. Don’t worry if you are not too comfortable in the beginning. Nobody is when assigned a new set of tasks. It is a natural phenomena to get conversant to ‘change’ that happens in life. Tune yourself accordingly and don’t panic with the situation at any cost.
5. The moment you accepted this new role, you knew that you can do it. So stop thinking negative about your fitment in managing your project. Someone in the top management already has confidence in you and that is why you have been given this role.
6. Look at the things around you in an organized manner. Start relating success, failure, teams, tasks, goals and you will be able to manage things in a better way. Plan accordingly and don’t change your plans so often.
7. Spend time with your teams who will help you in getting deeper insights of the project in hand. Ask their opinion on issues where you feel stuck.
8. Make your team managers owners of their teams and their responsibilities. Appreciate for their successes and help them where they feel they are failing.
9. Gel with the streamline of people in the project – teams, various stakeholders, management, customer.
10. Trust yourself.
Project managers are not out of this world entities. They are one among us but with a difference of managing things more smartly and effectively. Success does not come on its own. It takes lot of efforts and habits to inculcate to become a successful project manager. If we talk about top five habits of project managers, those can be listed down as below:
1. Have a structured to-do list: A number of times, in between some important meeting, or while performing tasks, some important piece of information about an action to be performed comes. Having a good memory is a blessing but not having a well organized to-do list is a curse. You compromise with it and you will soon get to know the negative impact of this on your life.
2. Don’t take breaks just for the sake of it: Having breaks is a good thing to refresh and re-energize yourself but don’t use it just for the sake of it.
3. Prioritize your tasks: Adding and managing you to-do list is one thing, prioritizing and re-prioritizing with regular reviews works like cherry on the cake.
4. Understand the best productive hours of your day: You can’t be equally effective and productive during all hours of the day. Understand what hours usually you are on top of your vigor and use it for finishing your most important tasks during those hours.
5. Don’t hesitate to do multitasking: Your brain is a complex processing unit and hence can handle multiple tasks at a time without any compromise with quality or delivery. Learn and understand your power to handle this tool.
In a business scenario lot of development requirements keep coming up from various functions. Each function is vital to business and hence can’t be ignored just like that. There has to be a measurable systematic approach through which the requirements are assessed and then accepted or rejected (or put on hold for the time being, depending on things in hand prior to new requirement). The measurable criteria can be formulated on following parameters:
Requirement: Try understanding what exactly is the requirement. Prepare a business case by drafting out exact functional requirements, its current situation, meaning how it is being handled currently; and what is desired, i.e. how the function desires this functionality to be handled through system, once developed.
Criticality: Understand the criticality of requirement from horse’s mouth. A function may be projecting it as a big deal but actually it might not be critical from management’s angle. Align everyone and then workout the volume of criticality of this requirement.
Urgency: The criticality, though would be the major deciding factor in defining urgency of this new requirement to be developed but there would be certain more critical requirements already in pipeline that need to be assessed before finally arriving at a conclusion.
Business Impact: A large requirement comprising of large volume of manhour efforts might have a little business impact and vice versa. Hence understanding the impact of this requirement on business is important to measure. Best way is to measure the negative impact on business if this functionality is not built and the positive impact it will bring in on the business after its development and deployment in the system.
Manpower Efforts: Definitely it is a big criteria playing role in deciding on taking a new development task, reject or put it on hold. At times, a very critical and urgent requirement, in lack of manpower resources in-house, might call for an outsourcing.
Whenever a new task of development comes to a development team, it encounters various scenarios that we are going to highlight below. The new requirement might be in shape of an add-on to an existing functionality, an altogether new requirement or a revamp of existing functionality. What various scenarios are faced when a requirement comes, are as below:
1. The development team (or a segment of the team) is just finished with its existing task in hand and hence is ready to take up the new task. Bang on! The slowing down train picks up the speed.
2. The development team has a task in hand that is about to finish in a short period. No worries! The new task in next to go. Sounds good.
3. The development team has a long list of tasks in hand already and there is no scope of taking this task as of now. This is a case of over choking.
a. A reshaping of priorities might take place here. The new requirement could come on top of the list
sliding all other requirements in the queue downwards.
b. If reshaping is not possible since all other tasks in hand are equally important and can’t be pushed
down, an immediate recruitment could take place to put new team on new task.
c. Recruitment of a team might not be very practical in such circumstances when the task is important,
critical and urgent. In this situation, an outsourcing is the immediate solution.
A situation may come during any project lifecycle when smoothly running train all of a sudden almost comes to a halt. When nobody in the train seems to be clear about their destination. When there is no driver vanishing out of blue. Or even if one is there, is not certain on where he is currently and what direction he needs to take further. That is what happens in a real project sometimes.
The stakeholders are unclear on what is the current situation and what exactly is the gap in attaining the next milestone. The Project Manager is lost altogether with no certainty about what was the starting point, where has the project reached, what all has been done, what is left, what is the next milestone, how to attain it; and so on. The teams are very much there in the scenario, but under such circumstances, are directionless, exhausted and unmotivated. Project manager doesn’t seem to have control of the situation. There is more of brick breaking, blaming and excuses for non fulfilment of targets during the review meetings.
Targets seem impossible to achieve. Customer requirements are lost or forgotten, teams reach to a higher level of dissatisfaction and management seems unaware of all this.
A project may be progressing well at a certain point but you can never assure the same situation of this project throughout. It could get entrapped into a bad situation at any moment of time and then it could go to an extent that it becomes an impossible task to revive it back. There is no single point that causes this situation of a smooth running train (project) to fall out and hence impact heavily on all passengers (stakeholders). It could get initiated by a single trigger or situation but then that trigger which is responsible to cause bad impact on a project could further be triggering n number of other factors or situations to add on to its bad impact and hence taking it to a worse condition.
The three major factors that could have escalating impact on worsening the situation of a project which could further cause a long series of chain reaction giving birth to various other factors are:
1. Loose control of PM: A project manager is supposed to have reigns of his project tightly controlled throughout the project lifecycle. The moment this control is left a little loose, things will go out of control, at times, to an extent, that it becomes difficult to assemble back the broken parts. A smart project manager would proactively sense the coming turmoil and would take appropriate measurements to avoid it.
2. Lesser Engagement of PMO: Where PMO exists only for the namesake it holds no control over the health and progress of a project, which leads to a difficult situation, most of the time.
3. Customer Involvement: When there is no involvement of customer during the project lifecycle, it works like a sleeping volcano that could erupt out any moment of time. The later, the more disastrous.
Well as discussed in the previous post, a project could be passing through either of the two phases – good or bad. As long as the good phase is on, nothing troubles except that you hate to thing about the bad phase you encountered during this or any other project. But when the project passes through a bad phase, there are a number of critical milestones that get affected and therefore impacts the whole project.
Let us look at an excellent video from projectmanager.com that guides a project manager on how to deliver bad news about project. What are the important do’s and dont’s for it to manage and hence handle the situation in a better manner:
Every project can have only either of two phases during its entire project lifecycle. It can be either running through a good phase or a bad phase. A good phase is experienced as long as everything is going smooth, things are under control, targets are being met by each and every individual and follow up meetings are more of an enjoyment. In this phase customer is also engaged heavily to showcase the tremendous progress of project during that phase.
But this phase does not remain intact or sustained all through. There are a number of factors responsible for this turnaround. Three of the top interesting factors that mar the progress of a project during its happy state to switch it over to the sad state could be: Loose control of PM over the project, Lesser engagement of PMO, No involvement of customer. This brings in the bad phase of a project. During this phase everything goes haywire. Nothings seems to be under control. Review meetings become painful and insulting, targets become far from meeting deadlines, customer becomes angry, teams become highly dissatisfied and so on. Let us see in next few posts what impacts it brings and how to handle those impacts.
A project manager manages a project in terms of managing teams, meeting deadlines and milestones, and so on. But project leadership is about something different. Where on hand project manager tends to perform what organization desires, on the hand, a project leader would not hesitate in finding out and declaring loudly what needs to be done in the betterment of organization. He will have a deep clarity of the gap what organization is desiring to get done and what needs to be done that is much better in those terms.
Project leader would clearly and crisply understand business requirements, prepare report on the gap and how to mitigate the gap, by doing different things or same things in a different manner. He would be more appropriate in chalking out technical requirements aligning with business requirements with proper amount of analysis. Another example can be considered in terms of management of database and applications. If a management report is required from various applications having data residing on different databases, one way is to extract all relevant data in a new database and then cater to the management report from this new database.
Another (and smarter) way of doing it would be joining databases and extracting desired data directly from it.
Most of the companies do not have a policy to ensure a well documented database. At times companies take up this exercise seriously and produce a well explained and structured documentation for the database in use but gradually with the frequent changes happening and new applications taking place, all this gets lost in dust of pressure of work or any other relevant reason that is proved valid/ genuine by the team responsible for it. It is bound to happen if this focus is not sustained and maintained ethically right since beginning.
Smart companies knowing the importance of this activity create a separate team for this job. This team comprises of a mix of various tech and non tech team members. There would be database experts, server architecture experts and technical writers which shall be the part of this team. This team’s main job to dedicatedly perform database documentation and keep it in sync with all changes taking place thereupon. If this documentation is not in place the situation acts as a hidden/ sleeping volcano that can burst at any moment of time.
Imagine a situation in a business scenario when a big expansion is taking place in terms of staff and resources. Definitely when there will be increase in staff there would be increase in users of various application thereby increasing the load on application and database servers. Now if there is no documentation in place, there would be no assessment on to what extent the current servers can take load and what exactly is the expansion required for servers.
Various types of Project Managers exist each having its own style of functioning and managing a project. Though it is an ideal situation where different flavors gel into one person and make him the perfect project manager. But that happens only in ideal and imaginary situation. Rest all situations strive on reaching to ideal level. That is so with the project managers.
Various kind of successful project managers can be listed as:
1. Visionary: This kind of project managers will be always at a very high level of energy and very clear about his goals and milestones for a period more than the average project managers stipulate for themselves and their projects.
2. Resource generators: These project managers are very resource rich all the time due to their charismatic nature, transparent behavior and diplomatic ways of managing the things. They are expert in bartering, exchange and pulling of resources from other project teams so as to fasten their own deliveries.
3. Innovative: These project managers never stick to a fixed project methodology for long. They always strive out for betterment, optimization, and management of resources available to them in a near to perfect manner.
4. Delegatory: They will be expert in knowing the pros and cons of any individual in their team and hence would be able to stretch or extrapolate the energy rich candidates. These kind of project managers know well how and what to delegate to each individual in its own manner so as to achieve the results well in time.
5. Guiding: They would be more delved into nitty gritty proceedings of their project by involving them in every task being handled by every team.
No Yelling: The 9 Secrets of Marine Corps Leadership You Must Know to Win in Business written by Wally Adamchik has been a well acclaimed book all across the globe in terms of having some serious thoughts about leadership. The book was published way back in 2006 and is still a popular read for anyone interested in learning about leadership. The book basically talks about main principles of leadership which are applied in Marines and gradually to any kind of business. As the title reveals that this book is about the 9 secrets of Marine Corps leadership.
The 9 Secrets of Marine Corps Leadership You Must Know to Win in Business by Wally Adamchik not only reveals these 9 secrets about leadership in managing tough and sturdy Marine Corps but it also educates you on how to deploy it vertically and horizontally across any kind of business to get a high level of success. Overall there are 9 chapters in the book, each for a secret. The revelation begins with the topic Integrity. In this chapter Wally explains the fundamentals of Integrity that comes from Consistency, and Trustworthiness. After revealing Integrity as one of the strongest tool for leadership, the next focus moves on to the Technical Competence. The secret is learning about difference between Technical Expertise and Technical Competence. As long as a leader is competent in technical aspects of any business, there is a scope of further learning and progressing whereas the expertise becomes a dead end.
Next secrets are Setting the Example, Self awareness, Taking care of people, creating new leaders, regularly revising or communicating the Commander’s intent, Culture and Values, Rehearsals. Each chapter is not only exhaustively interesting but also contains a number of useful stories from Marine Corps and Civilian Businesses.
For all projects in software conducted for Government of Uganda, the National Information Technology Authority of Uganda shortly indicated as NITA-U has prepared a comprehensive guidebook titled as National Project Management Methodology Guide which acts as a controlling and managing media. Any agency, for that sake, national or international, that is engaged by Uganda government for development of a new software product have to ensure adherence to the National Project Management Methodology designed and developed by the National Information Technology Authority of Uganda (NITA-U).
Basically the major components of this is to ensure coverage of all essential steps required to ensure structured planning, control and management of IT projects. By adhering to it, it is assured to comply with appropriate methods, procedures and policies so as to ensure that world class good practices become essential component, or rather a driving agent, for any kind of IT project throughout, for all stages during its lifecycle. A vast experience and collaborative knowledge has been put behind to manage the show. Previous IT projects, successes and failures; with in-depth analysis has helped in building a strong knowledge base from all kind of lessons learnt.
Well defined processes, procedures, templates and guidelines are critical components to ensure extensive direction to users to follow the same without fail.
No wonder if you get to know that the global demand of expert software testing professionals is increasing exponentially. There are, in general, two misconceptions about this profession – one, a technology/ engineering guy if does not succeed in software development business take testing as a professional; and two, that software testing profession is not as demanding and successful as software development. Both are not true. A failed developer, unless has a different kind of flair and a real passion for testing can never succeed as a software testing professional. On the other hand this is also a misnomer that if you are not a good software developer, you cannot become a good testing professional.
With the increasing demand for software and hence software testing services, there is a regularly increasing demand for software development professionals. Software development has become a strong and powerful industry in itself with companies strongly putting their foot forward in the global markets for providing specialized software testing services. These services include end to end quality control, quality assurance, testing training, testing certifications and so on. A raw or semi cooked product has no value in today’s stringent and highly competitive market. Testing has become a separate domain with a specific kind of requirements for testing specific kind of products or for using specific kind of testing tools. Today, testing is not merely a paperwork for just the sake of formality to impress customer.
Testing, in today’s scenario is a specialized profession with specific skill sets. It is as highly paying job as software development. In fact in industry, expert software professionals are being paid higher than their equivalent counterparts engaged in software development.
Quality software engineer may appear to be performing different roles. There are several instances where people might not be aware of QA or even if they are aware of this word they might now be aware about the functions of Quality Assurance. On the other hand you will find people who are well aware of this term and the core functions performed by Quality Assurance.
A Quality Assurance Engineer is supposed to be planning and executing activities defined in the quality system in a well structured manner. These major activities that a QA engineer is supposed to be engaged in defining of development processes during the development cycle including audits, reviews and refinement. Audit would include finding out deviations from the standard procedures and their closure. The role of a quality assurance engineer also includes defining processes and procedures to be followed at every stage.
A quality assurance engineer has a major role in documentation of policies, procedures and systems.
Respect is the biggest tool to draw out automatically many more winning strokes for a project. If a Project Manager has a charisma to inculcate respect within and across teams, it drives always to a winning note, bringing in momentum and thrust towards quick and successful closures to any kind of challenges. In fact respect among all team members acts as a catalyst to boost a project.
It is always a two way process with a top down approach. Organizations with a heart (& courage) are able to adopt it with clear cut visibility. It comes from top up to you wherever you are in the hierarchy and automatically goes downwards… It works like a chain reaction, a virus, a communicable disease (all in a positive note) working silently but with a loud bang! It all depends on how much weightage you give in inculcating respect factor among all working on a project irrespective of the level and forte of each member. Not all organizations understand the value and its long term benefits in investing such time of soft activities but definitely once someone sitting on top level, if understand it gravity, would always ensure that such kind of culture always exists.
Sustenance with a good amount of urge to keep its level rising automatically becomes target of everyone in the team, once it starts with full amount of sincerity and the teams (and each of the team member) starts tasting the fruit.
Requirement analysis is the first exploratory exercise that happens during a project management cycle. It is a phase in which a set of business analysts visit the customer location so as to understand the actual business process by witnessing the real business scenario and meeting with core process experts who are managing the business flow from various fronts so as to understand the core business process and thereby chalk out the business/ customer requirements.
Requirement analysts are supposed to have an expertise in various areas. One core area is they need to be good probers and observers. Probing tool must be used at the time of discussion with process and business experts from customer end so as to finalize the requirements. RA team members must use their observation keenly in order to understand the actual processes being driven. It is the customer who needs to understand clearly what process will take place in what manner after it is taken shape of a business application.
There is always a gap between any process being driven manually and that through an application. The flow of process may not remain as it is when ruin through an application. There might be some changes happening in roles, functions, authorizations and approvals.
There are certain shortfalls at both ends during any phase of a project that keep eyebrows raised, questions sparked and delays caused. Usually the mindset at the beginning of any software project at customer end is – since we are the paying agents we will be having an upper hand throughout. So even if there is a lacking in defining customer requirements at the beginning during the requirement analysis phase, from customer end, it is felt that those shall be given at a later stage. But at a later stage it would have a recursive impact on documentation, development and delivery – that nobody tries to understand a that juncture.
Similarly at the delivery end, which has a higher stake in technology, sometimes oversees capturing of concrete customer requirements and when this hidden bomb explodes at a later stage, it causes damages to a large extent in terms of time and money. Let us try and understand some of the key factors to improve quality of capturing of customer requirement so as to avoid any hiccups at a later stage.
1. Ensure the best of the person knowing ins and outs of the business process is part of discussion.
2. Ensure there is sufficient buy-in of the customer management in sealing the requirements.
3. Ensure that sealing of requirements does not mean there will be no change in requirements at a later stage. This sealing is as at that moment of time when these requirements are taken and recorded. There could be external (or internal) factors imposing new requirements.
4. Ensure that the team capturing business requirements from delivery end does not seal requirements sitting in a meeting room. They should spend ample time living in the process with full understanding in real scenario.
5. Don’t commit 100% delivery of requirements without consulting with internal teams at delivery end – business group, technical group and deployment group in the same hierarchy.
Customer is the main source of inspiration and motivation for the development of any product planned to be developed or launched. It is the customer requirements that are kept on top of mind while developing a software. Customer is the end user and various connected links to the end users who are ultimately going to use the product. If a product is developed with all good and great efforts put into it, but does not get at par with the expectations of the end customer; it is bound to fall flat on the floor.
Now if the customer requirements are so important and crucial, why during the phase of Business/ Customer Requirements Analysis, so many gaps are there that lead to big disasters at a later stage. There are gaps at customer end and equally at the vendor end. Let us look at customer end – when customer does not understand the gravity of matter or takes it lightly with lighter mindset. Customer thinking of handling the gaps at a later stage, that he is aware of at this crucial juncture; but also knowing that there is no later stage to handle such gaps which are important to build right at this stage.
5 Myths that a customer carries at the juncture when Business Requirement Analysis is being done, which lead to failure later could be:
1. I am very busy: Well, though I know the process to the core but right now I am very busy so please talk to xyz down the line who will explain you on the basis of whatever he knows.
2. I will manage it later: If things are not explained well right now (though they are supposed to be), don’t worry, we will manage them at a later stage (but when? at the time of product launch? thereby inviting a sleeping volcano to erupt)
3. If you have a doubt ask me: Though I am very busy even knowing that from customer end I am the rightmost candidate to explain the whole process but I am deputing someone below the line who has joined recently to explain it. And if he has any doubt anywhere, he will ask me. The poor guy doesn’t know where to ask what having his limited knowledge of the system.
4. I expect you to understand in 2 hours what I mastered in 2 years: I joined in the system, took my own sweet time to settle down and then understand the system. But when you have come to do the requirement analysis, I expect you to understand the whole business scenario up to the root level in a single meeting of 2 hours.
5. I focus more on how to build the process rather than explaining the process: I will keep poking my nose in telling you how to build this process in the system (though I don’t know even the ABC of software development) rather than explaining you the actual process with minutest of the critical details that are important to be taken care of.
Few facts about customer requirements:
1. Customer requirements keep changing during the course of development of a product.
2. It is damn critical to absorb customer requirements, expectations and untold dreams precisely and correctly in documentation and product.
3. Behind every line of requirement specified by customer, there are 10 lines which is important to understand and document.
4. Customer requirements is not only the beginning phase of a product journey, it needs to be revisited and reviewed, along with the customer, during every phase.
5. Customer requirements told/ specified by customer, not documented well is a disaster for the product.
6. Customer requirements not signed off by customer is like an unsigned cheque with whatever hefty amount written on it.
7. Customer requirements not aligned properly and accurately from RA document to product (during development phase) leads to a different destination with no end results.
8. Perception of a product before designing of product is more important.
9. Quality testing without getting into customer’s shoe is worthless.
10. Well designed product if not presented well at the time of delivery and deployment, to end customer highlighting all his expectations met as key features will not be taken as a rich product by customer.
You ask any software company about their first wish and it will be a consistent desire to produce quality software. Ideally it would be fantastic if the product goes beyond the expectations of customer in terms of quality but usually it never happens. EVery time a product is handed over to customer, it lacks some or the other quality related issues the way customer had wished to have it. There are sometimes certain limitations that are imposed in the new product as an alteration or deviation as it could not have been possible to handle the business requirements as it is.
Software quality can not be defined in a single set of words. There are certain criteria or parameters on which it can be measured. The parameters and definition of quality of a software for a particular customer (or set of customers) would vary depending on geographic and local requirements that can’t be fixed just like that. How about linking quality of product with the quality of customer requirements. So let us try to jot down below the various factors that impact on quality of software:
1. Quality of customer requirements
2. Quality of RA team:
2. Quality of Project Manager
3. Quality of Development Team
4. Quality of Testing
5. Quality of Deployment Team
6. Quality of Documentation
7. Quality of End User
8. Quality of training
9. Quality of Management
10. Quality of Methodology used for Project Management.
In next few posts we would be discussing these factors in detail. It is important to note at this point of time that each of the factors listed above is a significant contributor for the overall quality of software/ product.
This is about Kibo Robot Project in which Toyota is participating in which Kobo Astronaut is travelling to space to find out exhaustive interesting facts and findings. The robot named Kirobo will be accompanied by few of the human astronauts – Commander Wakata and his team. Toyota’s role in this project is quite phenomenal. The robot Kirobo is fitted with an advanced voice recognition software developed by Toyota team. Why Toyota decided to join in, in this project is because the company is hopeful of building up of a society soon comprising of both – human and robots – existing together and helping each other in the newly dreamt ecosystem.
That is why Kirobo is being sent to the international space where he will meet and interact with the human representative Commander Wakata. The new software is different from all other existing interactive voice recognition software. The different is phenomenal as the new software instead of being one question at a time kind, is more of human nature where Kirobo listens sympathetically and replies back accordingly in an intelligent manner.
Hope you enjoy this new project and the video embedded above.