Tag: Requirements

Making the Most of Bad Requirements on a Project

Written by Brad Egeland on April 9, 2018. Posted in Articles. 5 Comments on Making the Most of Bad Requirements on a Project

Good, complete, complex and well-documented requirements are the lifeblood of the project. With them, everything can run pretty smoothly for the duration of the project.

Design and development by the delivery team is dependent on them… so a good, workable solution is dependent on them. As is usability of the end solution by the end user population, right? So far do I seem on track as to the importance of good, detailed project requirements? What else? User acceptance testing (UAT) will have a tie in as on tech projects especially that is where testing scenarios and test cases will be built from and against. So a good user acceptance testing experience and confident outcome is dependent on having good, complete and well-documented requirements, right? Meaning final signoff on the project by the customer is at stake too…

So what happens on projects where requirements aren’t or couldn’t be documented well? What if the business processes or the project need is a bit unclear, so the project starts without well documented, complex and detailed requirements. Come on; we start long trips this way so why not projects? After all, aren’t truly full documented requirements in a very detailed form more of a luxury than a given?

How many of us have had everything spelled out as to what is needed to be accomplished before embarking on a project engagement? There comes the point when we’ve done enough planning – or really when we’ve spent enough project dollars and time planning and detailing requirements. When is that? When management or the customer sees from the budget forecast and project timeline that all of the planned efforts for requirements has been expended and that begin saying… “let’s get started already!” When this happens… you don’t have much choice… you move forward but keep these things in mind…

That re-work is possible and likely.

Whenever we are faced with vague issues during planning, then re-work during the project is possible and probable. Maybe the business processes are poorly defined, or the customer isn’t sure yet what they want (they will know it when they see it) or some similar scenario. Whatever the situation, when you’re building a solution with a roadmap that has gaps in it, you’re going to have some bumps in the road. Document whatever you can as potential risks, track all schedule deviations and manage project scope closely. Change orders are necessary for almost all projects, but we always try to keep them to a minimum so as not to risk issues with the project client. But they will be more likely on a project like this… which leads to my next topic…

Advertisement
[widget id=”custom_html-68″]

Change will happen.

Yes, on a project with less than fully documented requirements, change will happen. Clients usually aren’t too happy to hear “change order!” shouted from the rooftops, because it usually ends up meaning they have to pay more. But on a project like this, you have to make it very clear as the planning phase is closing and your client is pushing forward that the risk is high for re-work and the need for scope changes and change orders. If you’ve softened the news by declaring that early on, then the customer impact will hopefully be minimal and resistance to the change orders non-existent.

Timelines will move throughout the project.

With re-work and change orders comes timelines and dates missed or moved by the change orders. The impact can be worse than just changed dates and dollars though. It may mean you lack project resources to get the work done due to timeframe shifts or additional resources needed to cover new work that wasn’t originally planned. So onboarding, learning curves, and revisions to existing plans could all be necessary. Be prepared for this mess, because it could quickly derail the project if not monitored closely.

The budget must be monitored very closely.

I’m a proponent of watching the project budget extremely closely – to the point of forecasting and re-forecasting on a weekly basis. As I always say, “a 10% budget overrun is not too hard to fix and is usually deemed acceptable… but a 50% overrun is nearly impossible to recover from and may result in a failed project.” So, watch the budget closely – always, but especially on this type of project where expenses could mount fast – and you may be able to keep it on track. At least you’ll be able to raise the financial flag early and possibly fix the situation with a well documented and planned change order to cover the extra effort and expense as they are happening and not after the fact. It’s all part of that oh so fun project management responsibility called scope management. And never is it more apparent and needed than on the project that starts with poorly defined project requirements. So, good luck! You’re going to need it.

Summary / call for input

Starting the real work on any project knowing the requirements are more like Swiss cheese than you are comfortable with is a source of major concern for the project manager and team. It will take skilled leadership and customer oversight to keep the project on track and somewhat on time and on budget. This is not for the faint of heart nor is it a great situation for a less experienced project manager. If you can avoid one of these risky situations, do so… run. But since you likely can’t, and you’ll probably feel the adrenaline flowing for the challenge of it all, we push forward and seek project success where it may be very difficult to find. Plus, we may have been assigned to it for a reason and have no option but to make the best of it.

Thoughts? Have you been involved in many projects with vague or poorly documented requirements? Why were the requirements so bad or hard to collect? Was it a new technology or customer not really knowing what they really wanted? Please share your thoughts and experiences.

Is your business analyst failing your project?

Written by Nimil Parikh on March 20, 2018. Posted in Articles. 3 Comments on Is your business analyst failing your project?

Analysts are ambidextrous while dealing with business and IT for a successful project delivery.

This ability makes analyst a catalyst for achieving business process efficiency. What’s the secret ingredient for an analyst to be the most important piece of this puzzle?

With an ever changing IT landscape, business leverages IT to manage and optimize operations, thereby reducing the cost. IT provides a comprehensive solution to an identified business problem which helps streamline business processes and achieve desired cost reductions. With a right team, tools, techniques, resources and solution, IT can deliver marvelous results. Business analyst ensures the right alignment of business with IT to assure an intended delivery.

Oftentimes, the solution achieved is not the intended one. As a result, the solution has to be re-designed to fit the original or an existing business problem which incurs supplementary cost. Ultimately, the business won’t achieve the proposed cost reduction. This failure of not being able to deliver the envisioned solution starts a blame game between business and IT.

More often than not, the root cause of this problem is simple. Either the information was not processed right or the right information wasn’t processed. Who takes the ownership of processing information? Is this a responsibility of project manager or a business sponsor? The answer lies in the very basic principle of software development life cycle methodology. Most information processing happens during the requirements phase and the role responsible for it is a business analyst.

A business analyst is the person who not only understands the proposed solution to a business problem, but also identifies the scope and purpose of it. This enables a business analyst to identify and define the right requirements of the solution being implemented and then translates those requirements in an executable technical language. This is where the glitch happens.

In most cases, analyst translates a request/need into a functional requirement which tends to deviate from the solution holistically. Their inability to see a situation from an enterprise perspective wanes out their effort. In turn, they fail to gather the right information and process it right, which leads to undesired end state. This isn’t just a problem of requirement gathering and processing it, but also about sharing it. Not all information is being shared correctly with the right person at the right time. As a result, interpretation of the requirement changes from person to person, situation to situation and time to time.

Advertisement
[widget id=”custom_html-68″]

Business analysts can make or break a project with their ability to understand the request. If they make sure that the information they receive and share is correct, sufficient and relevant, projects can adhere to the intended delivery path, schedule and budget.
Business analyst being the bridge between business and IT, the most critical building component of the bridge is an ability to process the right information right. This skill set can be achieved with a combination of subject knowledge, domain experience and the right communication technique.

There are four major ways in which a business analyst can ensure that the right information is being processed in the right way.

1. Understand solution holistically

Analysts need to identify a business problem and understand the solution and its alternatives. They should examine the solution fit, perform impact analysis and ask relevant questions to the stakeholders and capture the information.

2. Requirements walk-through is a blessing

Once the analyst is confident of having gathered all the information required, it then needs to be mapped to the solution requirements. Once the requirements are authored, analysts need to set up a walk-through session with both business and IT to get their sign-offs on the expected delivery requirements which ensures that the requirements adhere to the project scope and the proposed solution.

3. Hand over the changes in a timely manner

Business is ever-changing and so is the business problem. As a result, project scope needs adjustment every now and then. Therefore, the solution has to adopt new changes coming in. These changes are disrupting agent for a successful and timely project delivery. Business analysts should always retrofit such unaccounted changes in the requirements. Pass on these changes as per the priority, either in the form of an emergency change request or as a post-delivery clean up item.

4. Use the kill switch when required

Not all requests or changes can be entertained. Some of them are just the noise. Business analysts should have an eye to identify the noise and be a gatekeeper. Use the kill switch when required. Don’t let the requirements fall prey to such noise. In worst cases, escalation is the right approach.

These steps won’t just let you be good at business analysis but will also ensure value addition to the overall project. I personally consider that a business analyst is not only a binding agent, but also a catalyst for the project. If you believe that my observation and experience needs maturity and learning, I’m glad to hear your observation, findings and stories.

With a strong belief that open minded people embrace being wrong, are free of illusions, don’t mind what people think of them, and question everything even themselves, I urge you to share your expertise.

When the Successful Project is Ending

Written by Brad Egeland on February 13, 2018. Posted in Articles. 1 Comment on When the Successful Project is Ending

You are the project manager and you and your team have just completed a successful launch of your company’s new accounting software that tracks everything from department budgets to project financials to vendor invoices and all costs associated with everything and everyone in the organization.

Planning and analyzing revenue, costs and profitability in 2018 will be a snap and you’re feeling pretty good about how the last 8 months went while leading this high tech and complex project and integrating all of the legacy data into it along with all of the data transformation activities that had to go into it as well.

You led a team of very skilled high tech professionals who were just doing their job, but did it well and collaborated and planned and designed the heck out of everything. With everyone running on all cylinders you delivered a very successful and satisfying end solution. Now what? You have just had a successful launch or are in the process of a successful launch. What do you do next?

Verify EVERYTHING is complete and signed off.

There are some long term knowledge base type stuff that you need to do and there should probably be some celebrating. But first let’s make sure all the loose ends are tied up on the project. That starts with the deliverables. Has everything been delivered? Are all deliverables signed of appropriately? Is user acceptance test (UAT) properly closed up and signed off with all issues resolved. Often that UAT is about the same as complete sign off of the final solution or system so that UAT completion and sign off is extremely important. I’m not saying get sign off on everything to cover yourself in case the client comes back because we’re mainly talking about a fairly successful project… but you never know and it’s better to always, always, always cover all of your bases and make sure everything has proper sign off.. good project or bad project.

Verify all invoices are out and hopefully paid.

In the same vein of making sure all deliverables have indeed been delivered and have been officially signed off and approved, you need to ensure that all invoices have been sent to the project client and that all have been paid. If there are any outstanding invoices with the client you need to follow up with them and find out why they haven’t been paid and if there are any outstanding issues that would make them not want to be finalizing the invoice with payment. Since the project we are talking about has been successful, it’s more likely to be an oversight on the customer’s side than any issue wth dissatisfaction with any overall work performed or deliverable provided.

Consider ways to promote the success.

The project was successful, team member morale is high and you want to capitalize while the momentum is in place and everyone is getting ready to head off to a next project assignment. What do you do? One way to promote the success is to send out a company-wide email or mini press release that highlights the success of the project with some details and calls out each team member to give them the recognition they deserve. It wouldn’t be a bad idea to draft something for a C-level to send out to all company employees as well – especially if this project had some visibility attached to it. Certainly you aren’t going to do all this for a $10,000 project, but you certainly could and should for a $1 million implementation.

Advertisement
[widget id=”custom_html-68″]

Conduct lessons learned for future success.

You actually had a successful project? I’m not saying that is necessarily a rare occurrence, but studies and surveys have shown that more projects fail than succeed. So knowing for certain that you have a successful project – not just probably a pretty good project that may be considered a success – is no small matter. So let’s understand what went so right and how your delivery team collaborated well to make it such a success. It’s likely that you or another colleague within the organization will be managing a very similar project in the not too distant future so having steps and practices and templates and documented decisions that went the right way would be good thing to help that next similar project succeed in the same way. Likewise, many of the successful actions can likely be incorporated into all company projects going forward.

How do we ensure that this knowledge is documented and transferred? We conduct a lessons learned session with all stakeholders to go through the pros and cons – and hopefully the cons on such a project are few – of the engagement to understand from all angles why it was successful. And, of course, even successful projects can do better… so there will likely be a few negatives to discuss and strategize on how to mitigate or avoid those issues in the future on other projects.

Summary / call for input

The bottom line is this… the project went well but you’re really not done yet. You need to ensure that all loose ends were tied up, figure out why it went so well so you can repeat it next time around, and commend those who participated because if you’re working in a matrix organization you’ll probably be working with them again. Project managers don’t get lots of accolades and you may not get any still even for the highly successful project, but don’t let that stop you from acknowledging all of your great project team members.

Readers – how do you feel about this list? You’ve had successful projects along the way – you must have if you’re still in the profession and you are reading this. What did you do to make sure all the loose ends were tied up and how did you give recognition to the team? Gifts? Movie tickets? Dinner out to a nice restaurant? Recognition? Announcements? You want to motivate them for next time even if they were just doing their job. But I’m not big on gifts personally…tell me why I’m wrong if you feel that way.

42, The Douglas Adams IT Project Management Experience

Written by Donato Piccinno on January 10, 2018. Posted in Articles. 3 Comments on 42, The Douglas Adams IT Project Management Experience

According to Douglas Adams the famous author of The Hitch Hikers Guide to the Galaxy 42 is the answer to everything.

The story goes like this. The most advanced race of beings in the whole universe decide to build a super computer to answer the ultimate question. They wait in anticipation for the greatest technical marvel the universe has ever seen to provide the answer. After the wait is over the answer is 42. The answer is so clever the most advanced beings in the universe cannot understand it. Rendering their creation absolutely useless. The story is a cautionary fable in the faith we place in technology and hyperspecialism to provide the answers to make the way we want to do things easier. Douglas Adams is more than an author. He is adept at conveying the outcomes when the human condition meets technology and process. The unintended consequences when humans do the human thing. Which is to do the completely unpredictable things the technology and process does not expects us to do. How very dare they! The audacity of it all! Douglas Adams quotes and thoughts can all be observed in action at the point IT solutions are conceived in the word of Enterprise Architecture then project managed into use by the real world. It’s the point where technology, human nature and process meet. Anticipating these outcomes well and things go well. A lack of anticipation normally results in unintended consequences. Where IT project delivery is concerned the same old story statistics on IT project performance from Standish and Gartner show a Douglas Adams observation in action.

Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.

We are classically trained to formulate the delivery of IT solutions with our scientific management head on. The ghost of Taylorism permeates every single way of working while delivering an IT project. The consequences are plain to see in the repertoire of Douglas Adams quotes. Missed deadlines, services that don’t meet needs, waste, cyber crime, disillusioned workforce and technology that fails to perform the moment it is exposed to the real world.

A common mistake that people make when trying to design something completely fool proof is to underestimate the ingenuity of complete fools.

I was actually inspired to write this piece following a meeting about rolling out a few laptops and phones. The experience was most humbling and ego destroying. I came away from that meeting kicking myself for falling for the illusion of control scientific management and technology can instil in us. For the meeting we’d come up with this text book rollout process for network, printing, HR, pcs, laptops and phones. Any methodical process type person would not fault it. But it had two fundamental flaws. For the process to work and give the final user the experience they were looking for everyone in the process had to follow the process. The key principle was 20 days prior to the IT solution going live the process needed to know the name of the employee. But in the real world a person could be employed on the day they needed the solution. Without the IT solution that employee would be sitting around for several days as a new starter request made its way through the process. The 2nd fundamental probably caused the team to miss the 1st fundamental flaw. The process was designed by experts who had no idea what it was like to be the user on the day they needed the IT solution. We knew what they needed from a functionality perspective but had no idea what it was like to be the user. So who were the ingenious fools in the Douglas Adams quote? The end user not following the process? Or the team that designed the process. IT project plans consist of activities from many different domains. Our plans are full of specialists i.e. legal, procurement, engineers, Infosec, HR, developers, architects, user managers, finance and the ITIL brigade. All insisting on something done in a certain way. I’m sure their motives are ulterior and it is always for the good of the company. But there is an inconvenient truth my comrades can fail to grasp. Unless experts design solutions or process from the point of view of the end user what is being insisted on is as much use as a chocolate teapot.

He was a dreamer, a thinker, a speculative philosopher… or, as his wife would have it, an idiot.

Again it’s the human condition and nature at work. As IT project delivery experts we like to think we are right even when we have zero experience in what the end user experiences. That makes anyone who thinks like that an idiot. The way around being an idiot during delivery of an IT project is to constantly check for experience shortfall within the team designing the process. A lack of experience in the experience of the end user in their operational environment is the experience shortfall. Secondly, involve people who have done what you are trying to do. Fail fast by rehearsing implementation scenarios early and often. Particularly, where the rollout environment has the following context:

Accessing the solution from or connecting to a heterogeneous network
Rollout sites are remote
Users are not tech savy
There is an inter generational gap between the project team and the end users

To give real service you must add something which cannot be bought or measured with money, and that is sincerity and integrity.

Advertisement
[widget id=”custom_html-68″]

Back to our user who has just been employed and walked in on the day of rollout. With my compliance and process adherence hat on I could say, ’Sorry we cannot give you a phone and laptop you need to do the job. Please liaise with your line manager.’ What if a whole organisations existence is about that particular type of user being empowered from day one. The beating heart at the heart of the house so to speak. The process compliance world tends to have a transactional relationship with the real world. As long as the real world behaves in a way that is a valid transaction. Everything is #peachy. If not, the tendency will be to try and get the real world to change. Which is fine until such a stance becomes dogmatic or a non-starter because the real world cannot be changed. An IT project delivered in that kind of culture is unlikely to perform on many fronts. Usability for ease of use and ease of deployment will suffer a dip in a performance. What if we rethink the project plan to rollout an IT solution based on principles or probity, sincerity and integrity? What if we view the user experience of receiving an IT solution as a customer experience? Would we end up with an outcome where on the day we say, ’Sorry we cannot give you a phone and laptop you need to do the job. Please liaise with your line manager to go through the process.’ No, a customer of the project would have their IT solution ready at the point the needed it.

Thinking of a rollout process from a perspective of customer experience management, probity, sincerity and integrity results in handovers of IT solutions where all user personas and real world circumstances get considered. Such thinking challenges the way IT solutions are designed to be accessed. For example, take cached credentials. Great from a security compliance point of view but as much use as a chocolate teapot in the rollout scenario below. With cached credentials the device has to be sent back to base.

Heterogeneous network
Remote sites
User details not known until the day they need the laptop or PC.

A prime example of the technical world not understanding the real world. Leaving the project wide open to the following outcome. Observed by Douglas Adams at the touch point between human nature, the human condition, technology and experts who lack understanding of the real world. The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair.

OUTSIDE THE BOX Forum: When is Agile Required?

Written by Robert Wysocki on January 8, 2018. Posted in Articles. 4 Comments on OUTSIDE THE BOX Forum: When is Agile Required?

We’ve all read articles that talk about choosing between traditional approaches and agile approaches.

Traditional projects can use an agile approach but agile projects cannot use a traditional approach.

There are some projects where that choice is a valid concern. But there are projects where some type of agile approach is not an option. It is a requirement. These are projects where the goal and/or the solution are not clearly defined or understood. In such cases the discovery of the missing piece(s) must be imbedded in the work of the project and that can only be achieved through some form of iterative process. Each iteration is an attempt to learn or discover missing parts of the goal and/or solution. After some number of iterations the goal and solution will be clearly known. To avoid an agile approach some traditionalists might try to jury rig their favorite waterfall model but that thinking is seriously flawed.

So complexity and uncertainty are the factors that lead to the conclusion that some type of agile approach is needed. But agile is a journey not a destination. There are several different agile approaches. So how do we choose the one that is the best fit given the project characteristics? Let’s try to answer that question.

THE COMPLEX PROJECT LANDSCAPE

The most intuitive illustration of the situation is the four-quadrant landscape defined by the two project characteristics: goal and solution. Every project has a goal and a solution to achieve that goal. Complex projects lack some clarity of goal, solution, or both and are found in Quadrants 2, 3 or 4. All of them will require some type of agile model.

Figure 1: The Complex Project Landscape

Agile Models Ranked from Mostly Defined to Mostly Undefined

After 25 years of client engagements where all types of agile projects were planned and executed I have adopted a ranking from mostly defined to mostly undefined. You might also use least complex/most certain to most complex/least certain. This is not an objective ranking. There are at least a dozen models that could be included. I’ve only chosen five for this article to illustrate the point. Each is briefly discussed. For a more complete treatment see [Wysocki, 2013]. The ranking is quite subjective but based on my personal experiences in using the models. There are also variants of each of these that affect their application.

Prototyping

This is a tried and true approach couched in the language of the client. There are a variety of variations from iconic models to production models. Prototyping is a very robust tool with a long history of uses including even the most complex and uncertain of project situations. Those would be situations where the project manager is using prototypes to suggest a starting point for the client to get on board with the search for a solution. Prototyping is a tool that keeps the client in their comfort zone during that search. It is quick and simple. There are several software applications that can generate and modify prototypes in real time.

Advertisement
[widget id=”custom_html-68″]

Evolutionary Development Waterfall

The only reason for using this is that it keeps the development team in their comfort zone. Project teams that have a long history of using the Waterfall Model will often choose this as their first step towards an agile environment. Unfortunately that is probably the only reason for using it when the situation calls for an agile model. It is very inefficient and wasteful of resources and time.

Scrum

The agile project world is dominated by Scrum [Schwaber and Beedle, 2001]. It is a sound model that keeps the client in charge through the Product Owner. That is, if you have a properly skilled Product Owner. Of all the common development models Scrum is a customer-driven model. Scrum does not have a project manager but the role is subsumed primarily by the team of senior developers, which operates as a self-managed and self-directed team. Co-location of the team is a critical component. Scrum teams tend to be small (less than 10 members). The temptation is to equate Agile to Scrum. There are many agile models of which Scrum is the most popular but the complex project landscape is broad and deep and can validly support a much richer portfolio than just Scrum.

Dynamic Systems Development Method (DSDM)

This model is popular in the EU [Stapleton, 2003]. At any point during implementation it allows the team to return to any previous stage in the design, development and deployment of the solution. DSDM is what the Waterfall Model would look like in a zero gravity world.

Effective Complex Project Management (ECPM) Framework

This is the new kid on the block [Wysocki, 2014] and [Wysocki, 2016]. It isn’t a model in the sense of the above. Rather it is a framework (Figure 2) that embraces a portfolio of models and a decision process for choosing and adapting the best fit model from the portfolio.

Figure 2: The ECPM Framework

It can be used for any agile project but is most useful when so little is known about the goal and/or solution that choosing and adapting the best fit model is not much more than a coin toss. it offers a decision model to help in that choice. The major advantage of using the ECPM Framework is that is designed to include the meaningful involvement of the client. ECPM is also a significant step towards establishing a collaborative project environment. Scrum includes that involvement through the Product Owner. The other models do not have meaningful client involvement as a design feature.

PUTTING IT ALL TOGETHER

All of these models and others should be included in the organization’s portfolio and the best fit one chosen based on the project’s characteristics, the organizational environment and culture in which the project will be executed and the market conditions the prevail. The specific types of projects the organization encounters might suggest that other models be included as well as customized models the organization has developed for repeatable projects. Choosing the best fit model is a multi-criteria decision. Preferences and availabilities have a lot to do with the choice. For example, Scrum requires more senior level developers because the projects are self-managed and self-directed. In the absence of senior level developers Scrum would not be a good choice.

[Schwaber and Beedle, 2001] Schwaber, Ken and Mike Beedle, 2001. Agile Software Development with Scrum, Pearson.
[Stapleton, 2003] Stapleton, Jennifer, ed., 2003. DSDM: Business Focused Development, 2nd Edition, Pearson Education
[Wysocki, 2013] Wysocki, Robert K., 2013. Effective Project Management: Traditional, Agile, Extreme. 7th Edition, John Wiley & Sons.
[Wysocki, 2014] Wysocki, Robert K., 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing
[Wysocki, 2016] Wysocki, Robert K. and Colin Bentley, 2016. Global Complex Project Management: An Integrated Adaptive Agile and PRINCE2 LEAN Framework for Achieving Success, J. Ross Publishing