If you are beginning to consider a move to more agile methods, you may be looking for a set of ‘best practices’ for agile requirements elicitation and agile requirements management. What you will likely find is many prescriptive and detailed ‘best practices,’ which I have personally found to be situational at best, and often just too much to consume for an organization new to the concepts. What I propose to offer in this post are a few ‘baby steps’ that can help an organization move toward an agile environment and prepare for some of the more prescriptive methods like SCRUM or eXtreme programming (XP).
When making a move toward agile methods, there are three main recommendations that I believe should be considered to prepare for a more agile requirements practice, and a team as a whole.
- Collaboration ─ While this is obviously a good idea in all methods of requirements management and all stages of a project lifecycle, it is an essential element to agile methods and agile requirements management.
- Embrace Change ─ This is almost a counter-intuitive step for many business analysts. To be agile in requirements management, we must acknowledge change happens, embrace it, and make it part of our process.
- Support of upper management ─ Becoming agile is an organizational change as much as a development practice, and without clear support from upper management, this change will be difficult, if not impossible.
Recommending good collaboration is a bit like recommending good work ethic; it seems as if it should go without saying. However, for organizations used to a very siloed waterfall method, real collaboration as a standard operating procedure may have fallen by the wayside. It can become easy in a waterfall method to simply over-document deliverables and blindly send them to the next team. In an agile method, an organization will begin to keep ‘living documents’ that constantly change and grow ─ this requires true collaboration and teaming. In order to include all members of the project team and stakeholders properly, an organization must not only take on more inclusive methods, but must educate all associated people on the use of the method, including management and stakeholders. If one expects individuals to be involved, the individuals must know how, why, and when they are expected be involved. Simply said, to create an inclusive method, all individuals associated with the project must feel and be encouraged to be involved. One simple step many larger organizations have found useful is the adoption of stakeholders’ terminology. Often in agile methods, we get very focused on the new names, terms, and roles ─ all at the detriment to collaboration. Many stakeholders will feel more comfortable with requirements, time periods, and project roles being expressed in their own terminology. This should be seen by the project team as a minor secession for the sake of greater collaboration.
Embrace Change. To many Business Analysts and Project Managers, this will seem counter-intuitive. As professional BAs and PMs, we have been taught to identify all requirements and lock down the scope. However, we all know change does happen, and what often defines the success of a project is how we deal with that change. Traditionally, an organization would manage this change with some sort of project or scope change management process, which gives a structure to altering requirements that are typically fully elicited. In agile methods, organizations acknowledge that change is constant in technology projects, and move to embrace that change. To make steps toward agility, an organization may need to change their requirements elicitation methods. The elicitation can begin with very broad requirements that outline a general scope, do some high-level requirements modelling, prioritize what has been captured, and prepare the team to change as needed. Once the broad requirements are documented and ranked, the team can then begin to add further detail to requirements in an ordered fashion. This means the stakeholders will give detail as it is needed, and the team will change documentation as details emerge. The stakeholders know their priorities and requirements will change, and the project team knows the project documentation is ‘alive’ and changing as the project moves on, and as the need for detail requires.
While the above-detailed steps are important ways to ease into agile, arguably the most necessary step is getting upper management support. The management lines for both the project teams and the stakeholders must understand the use of agile methods is an organizational change, and not just a development method. These management lines must fully comprehend the concepts behind embracing change, increasing collaboration, and the notion of practicing constant requirements prioritization. As with many successful organizational changes, the use of ‘on the ground’ champions of the new process are important, but a clear message of support by company leadership is imperative. A project kick-off that includes an executive saying a few words of support for the new methods and mentioning that management is watching for this to be a successful implementation will go a long way to drown out the voices of the detractors.
As an organization strives to become agile, it is important to remember to be agile in the implementation of agile. Meaning, only take on as much agile process and change as your organization can handle in each ‘sprint,’ or short change window; and only keep the agile processes needed to improve implementation of technology projects. Organizations can often lose focus of their underlying purpose for adopting agile methods, and begin to focus on ‘becoming agile.’ There is not a prize or reward that comes with completely adopting any particular agile method, so look to embrace the parts of agile methods you need to find your success, and question anything else — because that is truly becoming agile.
Don't forget to leave your comments below.
Kurt Solarte is a Managing Consultant working for IBM Australia in Sydney; focusing on Agile Development methods. Kurt recently spent eight years with IBM Global Business Services in the U.Ss as a Sr. Business Analyst; where he specialized in keeping business analysis alive and relevant in the agile delivery of eCommerce, web portal, and business analytics projects.
The potential benefits of a project management office (PMO) are numerous and well documented. However, many of the benefits never materialize. Take a look at PMOs over the years and you will see that many have restructured, dissolved, or constantly had to justify their existence during both economic downturns as well as high-growth periods. This is evidence enough that PMOs are not yielding demonstrable positive financial results. This churn often causes years of frustration for both the PMOs and the projects and departments they serve. Changing the way in which the PMO is chartered, works, and is perceived within an organization can ensure that it offers plentiful advantages for the entire organization.
Two Problem Scenarios…And Strategies to Solve Them
One: The PMO is spawned by an executive with a big problem
Most project managers have one. Yet attending to their demands and idiosyncrasies can be nerve-wracking. Wise project managers engage good boss management strategies. Boss support, guidance, mentoring and influence will be your reward.
After all, bosses are not exalted and invincible gods. They are human beings with special roles and authority as well as the requisite levels of human weaknesses, problems and pressures.
Under these demanding conditions, most boss relationships unfold in two possible directions: the 3Rs Resistance-Resentment-Revenge or the 3 Cs Clarity-Co-operation-Commitment.
There are many factors in an application implementation-related project that over time have proved to be key contributors to the success of such projects. This includes items that may seem obvious, such as solid testing, communication, and involvement by key staff members, but these are often under utilized in favor of saving time. When projects skimp on these key items, it is likely to result in:
Software projects rarely come in both on time and on budget, leading to dissatisfied end users. DeMarco and Lister, authors of Waltzing with Bears: Managing Risk on Software Projects, discuss five different risks associated with software project management, including schedule flaws as one of them.
In this article, we’ll discuss several symptoms and causes of schedule flaws, present metrics and diagrams that can be used to track your team’s progress against its schedule, and describe Agile ways to address these risks.
‘Our customers really love us, so they don't care if their projects are late and don't work.’
Is this what you think? Is this what your project ‘customers’ are really saying?
How about this?
‘We figure it's more profitable to have 50 percent overruns than to spend 15 percent on project management to prevent them.’
Do you ever get to hear that one?
The establishment of PMOs is a daunting task that requires great wisdom and perseverance. What is of paramount importance for the PMO’s success and longevity is to make the management of executive interests an intrinsic feature of PMOs, while weaving them into the very fabric of the project organization. This implies that the design and construction of the PMO must happen organically, i.e., the structure of the PMO cannot be imposed or rushed, but must develop naturally. However, in practice, there is a strong impulse to simply ‘cut & paste’ PMO solutions. This is often done without a correct understanding of the problems affecting projects and possessing an inaccurate assessment of executive views on role of the PMO. In most cases, PMOs are established based on an arbitrary executive instruction. The purpose of this article is to explore techniques on how to analyze and assess what executives really want from PMOs.
I attended a presentation given by John Reed of Westreed, a brand consulting group. Mr. Reed provided some great tips to help you connect with people in writing like you connect with them in person. As professionals, we are always trying to get others’ attention in writing. You are probably taking a break from writing an email to read this blog. Most people receive on average 100 to 300 emails a day. And they are not reading every one they receive. What are you doing to make sure people stop, read and respond to your emails? Here are some of the tips Mr. Reed shared.
There are three areas to focus on when writing: 1) get attention, 2) get understood and 3) get a response. Let’s look at each area.
- Use a headline to catch the reader. Come up with a headline that answers a key question the reader will have; “Why should I care?”
- Make it easy to read or scan the communication. Don’t have one big paragraph. As an example, use a short introduction paragraph, three to five bullet points for the body, and a short closing paragraph.
With email communication, take time to think about the subject line and make sure it pertains to the content of your email. The subject line should be used like a headline for a newspaper article. Resist hijacking another email string to start a new thought. Start a new email with a new subject line.
Mr. Reed shared a four-step process to get started writing quickly and make sure your points are made. This is very similar to an approach I use to write my blog posts!
1. Start with a brain dump. Just get information down.
2. Throw away the junk. Read through your brain dump and start removing content that is not needed.
3. Box and label the valuable stuff. Group thoughts and give each group a label.
4. Clean up and edit. This is the last step. Resist the urge to edit as you go.
Prior to me learning a similar strategy, I remember feeling paralyzed sometimes and couldn’t even get one word down. Here are some other helpful hints to help you get started.
- Start with the easy stuff. Don't feel like you have to write linear. You don’t have to write the intro, then the body, then the closing. Start with what is easiest for you.
- If you are struggling writing. Write in question-and-answer format. What questions will the reader ask or need to know? You may not want to send a communication that way, although you can. But, at a minimum it will help you get some thoughts down.
Get a response
Some of our communication is for informational purposes only, but much of what we are doing is looking for some action to be taken. It may be you want the reader to make a decision, review a document, provide feedback on the information shared, etc. Always ask for a response and make it easy for the reader to respond. If you want someone to call you, share your phone number…don’t make them have to search for it. If there is a document you want them to read, attach the document or provide a link. Don’t say something like “download the document from our project SharePoint site.”
The final thought shared by Mr. Reed was the 24 rule. Write something and wait 24 hours before you send it. If you don’t have 24 hours, wait 24 minutes. If you don’t have 24 minutes, at least wait 24 seconds. It helps to get something down and re-read it later after you stepped away from it. By the way, I just waited 24 seconds to re-read this!
To better communication,
Don't forget to leave your comments below.
What is UAT?
User Acceptance Test, or UAT or Acceptance Testing, all defines the single meaning.
According to The International Institute of Business Analysis – Body of Knowledge V2.0, User Acceptance Test or UAT is defined as "Test cases that users employ to judge whether the delivered system is acceptable. Each acceptance test describes a set of system inputs and expected results."
User acceptance test refers to the satisfactory test of solution by users before moving the solution to LIVE Environment. In UAT, users of the software validate the maximum possible scenarios that may come in LIVE environment, which are tested in the solution and found to be accurate.
If UAT is about testing the solution, then a question comes to mind: "What do Quality Assurance departments do at their end when they say they are testing the application?" For that I would simply say, there is a 360-degree difference in both types of testing, and the biggest difference is the goal/objective of both.
The goal of software testing is "to make sure the software meets the specification" or "to make sure that the developed software is bug free."
Whereas the goal of User Acceptance Testing is "to make sure that system completely supports the day-to-day business scenarios along with other known possible scenarios that may create a hurdle in business operations, and to make sure that software will not hurt the LIVE operation when it will be running in a LIVE environment."
UAT is considered a final stage of any software development initiative. Without successfully completing the UAT, the project cannot be considered as completed nor does any client accept.
While discussing the project issues with different colleagues, friends, community members and others, I have found that many Business Analysts try to implement the system directly in a LIVE environment, i.e., user starts entering LIVE entries and when all entries are entered and reports are matched, the system is considered as implemented and signed off.
Exceptional/abnormal scenarios are part of routine business, and they are also very hard to recall/identify. In the earlier-mentioned situation, when the user was focused on testing the system based on LIVE entries only, he definitely loses the focus on those abnormalities that arise usually in his business transactions. Further, there might be some special cases that were handled in some other way by the users; those cases will also be missed in testing based on LIVE data. All of these abnormalities, special cases and others issues will come someday in the LIVE environment when the user will be using the software, which will be the time the user will say, "I used to solve this case by pressing that button in legacy system" or "I did this case by doing this, this and this," and the vendor will ask for Change Request and two things will be charged (money and time), and due to time the business may suffer.
Consider the other scenario in which the user took his time with the business analyst and identified the maximum possible scenarios including normal/routine business transactions along with any abnormality or exceptional scenarios. And when the system is ready, users test all those scenarios in the system and after successful completion of testing, the system goes LIVE. This will minimize the chances of abnormality or exceptional cases in the LIVE environment.
Conducting UAT is equally important for both Vendor (Software Developer) and the Client (Software User). Thousands of reasons can be written on the importance and impact of not doing UAT; following, are some very important reasons for which UAT should be done in every project.
Reduce chances of error in LIVE Environment: Maximum possible scenarios are identified and tested before software moved to LIVE environment
Increase User Satisfaction: UAT provides full-fledge access of software to user, which gives him a lot of confidence as well as satisfaction to allow him to test the software that soon he will be using in a LIVE environment
Reduce risk of regulatory & other compliance: As in UAT, the system is tested on maximum business scenarios; the risk of regulatory and other compliances that may bring penalties in term of financial impact, opportunity loss or customer dissatisfaction can be minimized.
Reduce Time: In new/automated system, there is a chance that the system has automated some business processes along with some changes in existing processes, which might have increased some process steps found to be unnecessary or wasting time in the LIVE environment, UAT allows users to identify those unnecessary steps before going into the LIVE environment, it allows organizations to save time by reducing process steps that may take time in the LIVE environment and incur extra costs.
Business reputation: If due to software solution, organization is unable to provide the services to its customer or provide the services with delay or somehow impact customer by giving wrong figures or showing wrong transaction in customer's account, this may blow the business reputation and definitely results in customer dissatisfaction, and with this, the company may lose a good amount of business that was successfully in hand having the legacy system in place.
Role of Business Analyst in UAT
Business Analyst as a neutral, non-technical, business side representative makes a good UAT conductor. Due to his focus of solving business problems, independent from developer and not having a technical mind, he can easily think in the shoes of the customer to identify the normal as well as complex, uncertain and abnormal scenarios along with real like data and help users in testing the same before going into the LIVE environment. And finally, the Business Analyst has a vested interest of high-quality software along with the solution of the business problem with value addition and so is motivated to perform rigorous testing of the system.
Skills Requirement of Business Analyst for UAT
As mentioned earlier, UAT is the last and final stage after which the system will go LIVE, and therefore, the crust of this activity is to make sure that maximum scenarios are tested in the system and if issues are found they are reported accordingly. Due to the criticality and importance of the UAT phase, the role of the UAT conductor requires multi-faceted skills. These qualities allow the person playing that role to perform this important activity; the business analyst must think in the shoes of the user to understand his problem. Absence of these skills may fail the overall UAT phase.
Further, following skills and competencies are required to be possessed by the Business Analyst to conduct effective/successful UAT:
People Handling: Business Analyst that holds good skills of people handling and can develop a good relationship with users in order to explain his point of view, and that skill also helps business analysts to understand the point of view of users. In UAT, users sometimes try to resist change or try to imply his point, but having a good relationship with the business analyst, the issue of ego doesn't come between and things get concluded in a positive direction.
Domain Knowledge: As quoted in every business analysis-related article, "Domain Knowledge is mandatory for Business Analyst." Off-course[G1] , if a business analyst lacks the domain knowledge, he will not be able to conduct the successful UAT. Due to his limitation in business knowledge, he will not be able to identify the business scenarios, nor can he help the user in identification of the same, and also will not be able to question the wrong scenarios or wrong practices that the user requires to be added as scenario in the software.
Software Functional Knowledge: You must have heard a business analyst saying, "I need to talk to my technical team to get the idea how this screen will work?" Consider the confidence level of the user on the business analyst and software when a person who is facing him is telling him how to do UAT? Don't know about his own solution.[G2] Business analysts must understand the inside out of the whole solution; I would say, "He should be the person who has maximum knowledge of software working." With this skill set, he can conduct efficient UAT, as the issue of stuck due to software functionality.
Executor, Initiator: Business analysts should have the skills of execution; he should have the ability to drive the users according to the UAT Plan and in case of any issues related to user availability, system errors, other resource availability, any other showstoppers or issues of progress, he should escalate it to the right person immediately without wasting time. Business analysts should observe the situation and inform the relevant stakeholder in case he senses some risk or issue that is arising.
Positive Attitude: Business analysts should always maintain a positive attitude and consider the comments of users as areas of improvement and act accordingly rather than start being defensive or sometimes offensive about it. He should understand the user's point of view and in case the user is of a different mindset, try to convince him positively with rationals[G3] and arguments to support his opinion.
Common UAT Problems Faced by Business Analysts in UAT
1. User Availability: Issue # 1 of any UAT, even if users are marked as fulltime user to the project, still they will not be able to give you required time, due to their involvement in day-to-day operations. As most of the time organizations find it difficult to execute the full-time strategy, because the user assigned to automation project are usually more skillful than others in their department, and assigning them to the project for fulltime impacts the day-to-day operations of the organization, and if the organization is ready to do so, it will require their users' interactions, which again impacts the user availability for UAT. Therefore, business analysts should maintain the record of user availability and escalate if user is not available as required for UAT.
2. Detail-Oriented Personality: There are some users who have a very detail-oriented personality or, in order words, they are perfectionists. These users are very hard to handle due to their expectations and requirements; they always want everything completed precisely and in detail. And their focus on detail drives them to the complex scenarios that a business has never faced before and might not face in the future as well, but they insist on testing those scenarios or handling of those scenarios in the software. That type of personality eats your UAT time like a grasshopper eats the grass. And as they are perfectionists, it is usually hard to explain your point of view to them and they also sometimes face problems in understanding the point-of-view of others, which moves the UAT phase into a never-ending cycle. But the important point that should be highlighted here is that this type of personality is problematic in UAT but can be good utilized in the requirement phase due to their detailed understanding of the business process.
3. Overlooking Personality: In UAT, you may face a personality that is easygoing and will not put required efforts on details of the system and its testing. This is the personality that will tell business analysts that "Everything is fine, all is good." That type of personality focuses on getting things done with simplicity; they sometimes do it because they don't know about the pain they will be facing if UAT is not done effectively. That type of personality is very high risk for UAT as the chances of overlooking functionalities are too high, and Business Analysts should identify that personality and handle it by going into every detail and letting that user think that BAs want him to go in detail along with escalating the issue to the right level if required.
4. Issue Log Management & Prioritization: In UAT, many issues are identified, and if they are not logged and prioritized at right time, the whole UAT exercise will go wasted. While doing UAT sessions, the user identifies many issues related to application, and there could be a lot of issue types, some of which could be "GUI Related, Logical Observation, Application Bug, Business Not Mapped" etc. The bigger software has a greater type of issues along with their number as well. As a BA, you should follow a good mechanism of logging and managing the process of issues. Every issue reported should be logged-in in enough detail to be understandable by the user and technical TEAM both, as those issues will finally be reported to the technical TEAM for resolution. BAs should also consider scoping at this level, because there might be some issues that were not in initial scope due to "requirement not discussed" or some other reason. Those issues should be reported in log but BAs should identify them as "Out of Scope" and set the expectation of the user that this will not be handled in the current release of the software.
5. Understanding of Requirements: It has been observed that Business Analysts who are conducting UAT with user and were part of the initial requirement phase (Software Requirement Specifications Phase) were able to conduct the UAT more effectively than the business analysts who are assigned directly to UAT without their involvement in SRS Phase. This is due to the understanding of requirements, as if the BA is involved in the initial requirement phase he would have better and a detailed idea of what the specific requirement is all about, and if he is not, he might have his own point of view in place for specific requirements that create hassle for the user who is doing the UAT. Therefore, the recommendation is the BA who is doing UAT should be part of the initial requirement phase, and if he was not, he should go through each requirement in enough detail to understand the different aspects of requirement and its implications.
6. Complex/Demotivating/Offensive Personality: In projects, you face different types of personalities, and all of them impact the project in different ways at different stages. You might have seen some personality in your projects who used to say, "This project is not going to work," "This project is Pandora's box," or my favorite, "We are playing GIGO (Garbage In Garbage Out)." Complex, demotivating or offensive personalities exist in projects and BAs cannot afford to avoid them. Good BAs should understand how to work with those personalities And how to get maximum out of them without going into never-ending arguments. These types of personalities are not very hard to handle and Business Analysts can handle them by maintaining his positive attitude, good relationships with individuals and good arguments to support his decision every time. And if things get uncontrollable, then BAs should know when and to whom the matters should be escalated.
Tasks performed by Business Analysts in UAT Phase
While doing UAT, business analysts perform different tasks based on the type of projects, duration and organization standards. The following tasks are generic to be followed in every UAT:
- Solution Validation: Validate that solution meets the Business Requirements
- Verify the Organization Readiness: BA should make sure that the end user is ready to use the software, by checking that the required resources along with relevant tools and trainings are delivered
- Identification & Validation of Scenarios: BA should identify scenarios that will be tested in UAT Phase and get those scenarios validated from end user
- Create Training Plan: BA should publish the training plan to engage the required resources
- Create UAT Plan: BA should publish the UAT plan so that required resources can be arranged
- Conduct the training of software: BA should allow user to do hands-on UAT by providing training of software, so that user satisfaction can be achieved
- Conduct UAT: UAT should be conducted keeping in mind the objective of UAT, which is to "make sure that system fulfills the day-to-day transaction of business along with any other known exceptions"
- Record the Results: UAT can only be effective if issues are logged religiously
- UAT Feedback: BA should from time to time confirm from user that solution fulfills the business needs as anticipated by user and update the feedback to related stakeholders
- Conduct UAT Signoff (Approval to GO LIVE)
Documentation created by Business Analyst in UAT
There could be different sets of documentation a Business Analyst does in UAT. The type and level of documentation is totally based on the methodology of the overall project, type of project and organization standards. E.g., By following the Water Fall, methodology in overall projects the level of formality in BA documentation becomes high and the number of documents increased, whereas in Agile there are low numbers of documents due to the low level of formality.
Following documents has been found to be useful for Business Analysts in the UAT phase; for better understanding, the list of documents is divided into sub-phases of UAT:
- Business Process Flows to make sure that user is doing the right things (Must Have Document) Download Template
- Application Process Flows to map the business process on application to support user in identifying the relevant screen for each business process step (Must Have Document) Download Template
- Deployment Things To do to make sure setup/primary data is ready with user before initiating the UAT along with any other resources (users, trainings, machines, etc.) that are required for UAT Download Template
- Deployment Slip on successful deployment of application on client premises Download Template
- Training Plan to schedule the resources required to provide software training to users (Must Have Document) Download Template
- Training Script: This document is to prepare BA for the training and UAT session, in which BA identifies what screens he will be training and by entering what data and how?
- UAT Plan to schedule the resources required to conduct UAT (Must Have Document) Download Template
- Training Signoff: User has accepted that training is done (high formality) Download Template
- UAT Issue Log: Should be maintained at any cost and shared with all stakeholders (Must Have Document) Download Template
- Daily UAT Summary to inform all stakeholders about the daily progress of UAT (Must Have Document) Download Template
- UAT Signoff is authorization from user to GO LIVE Download Template
- Customer Testimonial
Don't forget to leave your comments below.
Abubakar Munawar, is a Trainer, Mentor and Consultant for Business Analysis, Process Improvement & Reengineering. He is a Business Graduate with over ten years of experience in Business Analysis, Software Designing, Development, Quality Assurance, Implementation Project and Product Management. He is working in Lucky Cement Limited as a Deputy Manager Information Technology and earlier he was a Project Manager & Lead Business Analyst with Plexus Private Limited for Investments Applications Division. He has conducted many corporate training programs for in-service personnel of large organizations in Pakistan.
Many of the clients we work with are a “PMO of one.” Usually this person has been brought in to establish common processes and procedures around planning, managing and executing projects. Most often, there is a broad spectrum of project work being performed by varied project teams within the organization, including a range of maturity levels spanning from no established, repeatable processes to very formalized and documented processes.
According to the Project Management Institute, “Companies with greater maturity should expect to see tangible benefits that include better-performing project portfolios, efficiencies that come with better resource allocation, and increased process stability and repeatability.” [i] On the other hand, companies that are less mature tend to be reactionary, trying to dodge problems as they come rather than strategically planning and executing projects. Often, these companies have various groups working in their own silos, so there is no centralized view of resource availability or up-to-date project status. Project managers are consequently unable to prioritize projects or schedule them with accuracy. This can lead to lost opportunities and failed projects time and again. A new study on organizational maturity has confirmed the need for defined repeatable processes, finding that companies that use them have a much higher project success rate than those who do not. [ii]
So how can the “PMO of one” bring teams and processes together to get everyone on the same page, speaking the same language and doing things in similar ways? Here are some things to think about for establishing common project processes that can be adopted throughout the organization, providing better performance and tangible results.
Focus on the Critical Business Issue
There are a number of reasons why an organization would decide to unify its project management processes. It could be a response to client pressure, a desire for an additional competitive advantage, or part of the general evolution of the company. Other times, the lack of organizational maturity is leading to lost opportunities. Understanding the reason behind the shift will not only give you direction as to how you should approach it, but can also help project managers to find creative ways to address the issue.
Don’t just establish processes for the sake of establishing processes. Rather, let the fundamental issues you’re trying to address or avoid drive your direction. You might find, for example, that re-engineering your processes isn’t what you need at all. Perhaps providing increased transparency, visibility and collaboration around all of the projects across the organization better addresses the critical business issue.
Transparency, Visibility and Collaboration
Adding transparency, visibility and collaboration to your projects is integral to achieving better organizational performance. In a recent article, Gina Abudi recommends a central system or “portal” as a means to implement best practices and improve project results. [iii] This does not, however, have to be an overwhelming PPM solution. A simple, easy-to-use system to interface between time tracking, resource management and project scheduling allows businesses to retain processes that are currently in use while still benefiting from increased visibility to crucial data.
Software alone will not solve your critical business issue, but it can serve as a hub that provides one “pane of glass view” for all processes throughout the company. Keep in mind that it is necessary to choose the right system for your organization. A few key requirements are as follows:
- Improved visibility of resource allocation, including project work, non-project work, vacation, etc.
- Real-time status information across all projects with warning indicators and alerts
- Integration between work requests, schedules, resource management, project roadmap and prioritization
A system that provides these benefits will enable project managers to focus scarce resources on the project that are most profitable. Project managers will also be able to keep track of which projects are on time and which ones are not, helping them to take immediate action as needed. Finally, they will no longer run the risk of scheduling a project under the assumption that certain resources will work on it, only to find out later that the resources are already allocated or will be out of the office.
Leverage What You Already Have
Just because you are trying to improve your organization does not mean that you should blow everything up and start over. Chances are you have processes currently in place that are working, and you should leverage these to get you to the next level. For example, you might find that despite the varied maturity levels, experience and background within your organization, most people are using Microsoft Project™ and Microsoft Excel™. A “rip and replace” approach where you force everyone to stop using these tools and start using a different system could have very adverse effects. Instead, you might look at how you can enhance and extend the tools, allowing people to keep the processes they are comfortable with while maximizing benefits and value.
Abudi agrees that you need to learn about what is currently being done throughout the organization before you try to make a change. Only then can you “discuss how standards may be developed organization-wide using a composition of processes already developed and being successfully implemented and filling in the gaps with new processes where needed.” In other words, rather than taking a standard like PMBOK® or PRINCE2® and forcing everyone to change their processes in order to uphold it, you can be a little more creative, retaining the things that work and improving or replacing the things that don't.
Communication is also important because many employees will be resistant to change. They might be suspicious of your efforts to improve processes when they feel that the status quo is “good enough.” (Remember what Jim Collins wrote in his book, Good to Great: Why Some Companies Make the Leap and Other Don't: “Good is the enemy of great.”) It is important to instill trust in these people so they understand that you are not looking to replace their current processes, but to improve and enhance them. Buy-in from your team is necessary in order to achieve success because they are the ones who will be helping you to reach your goals.
Better Project Results
Whatever you introduce is going to represent change, so it is important to understand how much change the organization and team can take and be mindful of that. There is no silver bullet, and something that worked for one company may not be a good fit for another. Only you will know what your needs are, what will and will not be adopted by the organization and how much time, money and energy the organization is willing to spend in comparison to the potential return.
Don't rely solely on software either. Remember to integrate your processes and people, and manage them well. Your software solution will need to empower team members and facilitate their work.
By evaluating existing processes, organizations can replace the weaker ones and maintain the stronger ones for optimal success. Integrating these processes in such a way that everyone involved in a project is on the same page provides a way to learn from your failures as opposed to repeating them.
Don't forget to leave your comments below.
Curt Finch is the CEO of Journyx. Since 1996, Journyx has remained committed to helping customers intelligently invest their time and resources to achieve per-person, per-project profitability. Curt earned a Bachelor of Science degree in Computer Science from Virginia Tech in 1987. As a software programmer fixing bugs for IBM in the early ‘90s, Curt Finch found that tracking the time it took to fix each bug revealed the per-bug profitability. Curt knew that this concept of using time-tracking data to determine project profitability was a winning idea and something that companies were not doing — yet…Curt created the world's first Web-based timesheet application and the foundation for the current Journyx product offerings in 1997. Curt is an avid speaker and writer.