Data Warehousing and Business Intelligence Tool Evaluations

Startup Stock Photo

by Plaster Group’s Data & Analytics Team

At some point, most organizations find themselves evaluating new tools to improve and modernize their data processing. The approach taken when making these decisions is incredibly important because it will affect many aspects of the organization including budgets, the development processes while implementing the tool, the operational processes to monitor the tool once it is moved to a production system, and (most importantly) the business users and/or customers. I have witnessed a number of different approaches to performing tool evaluations — some more effective than others.

Companies sometimes simply look to research organizations such as Gartner and assume that if a tool ranks as a market leader in their “magic quadrant” that this is sufficient to determine a tool’s effectiveness for their needs. Another approach that I have seen is choosing a tool because your company and the company that sells the tool have common board members – a truly bad idea and a conflict of interest. Or, companies sometimes keep an existing tool that does not meet their current or future needs because of concerns for the time/complexity of converting existing application code. Although these approaches yield a quick decision, the end result is often a tool that lacks key functionality to meet business requirements, and that makes processing data into information a daunting task for development and support staff.
Instead, spend extra time up-front to determine your organization’s specific needs. This will ultimately lead to a better purchase for your organization. Ideally, requirements should be put together by a cross-functional group of individuals from across the organization. This group will include engineers, support staff, management, and business users. Requirements should be identified across a broad range of areas such as:
  • vendor support
  • operating system requirements
  • security requirements
  • ease of hiring or training development staff
  • database support
  • ease of business user access to reporting and ability to build their own ad hoc reporting if necessary
  • licensing costs
  • ease of installation and maintenance
The above criteria should be used to pare the list down to a handful of top contenders. Then, the vendors should be brought in to demonstrate their product, ensuring that the tool functions as expected and works well with the organization’s existing systems and databases. For each requirement there should be an appropriate number of tests that span a distribution of easy, medium and complex tasks. When presenting the results, include scores that reflect the degree of difficulty to accomplish each task, the complexity of the solution, and the time necessary to implement and to run the task.
While this more comprehensive process requires more time and effort, it will keep your organization from having to trade up to a different tool because the initial one chosen did not meet the organization’s need. More importantly, this approach enables better application development, more effective operations, and improved solution delivery.

Starbucks Chorus @ Benaroya Hall Benefit

On May 1st, Plaster Group Agile Consultant Aki Namioki, a member of the Starbucks Chorus, performed in their benefit concert at Benaroya Hall. The benefit had a great turnout in support of organizations including Saw Horse Revolution, Downtown Emergency Service Center, Pike Market Senior Center, and Real Change. Read more about the concert on the site Starbucks Melody, and check out this great clip of Street Requiem!

 

PMI & Agile


by Shama Bole, Sr. Agile Consultant and Client Service Director

What grew as a creeping sort of dissonance over the past few years, in my role as project manager using Agile methodologies, has now coalesced into full blown discomfort around the question of whether the Project Management Institute (PMI) can relate to Agile. Recent readings, events and classes have featured the PMI attempting to play a central role in herding Agile into the fold of PMI-sanctioned methodologies. This article is based on my understanding of the PMI’s stance as viewed through these classes and readings. The PMI’s pitch is that Agile does not address ‘macro-level’ challenges for project management, and that this gap is covered by the PMI. The PMI claims that every Agile framework is missing two critical elements: sophisticated scheduling tools and account cost management. My take on this is that the PMI is struggling with a methodology that is outside of its paradigm and understanding.

PMI v Agile

Micro v Macro: As regards macro – or enterprise – level solutioning I’m not convinced that there are gaps that Agile methodology fails to tackle. Rather, it is a failure on the part of organisations like the PMO and Finance and HR that fail to support a changing milieu, whether in the realm of budgeting and financing of Agile projects or performance management by rewarding individual efforts rather than teams. The PMI takes the same approach as that of micro-level execution and escalates it up to the executive level, substituting – at random – ‘executive management’ for ‘delivery team’. I do not see any clear vision or pathway in the PMI’s approach to Agile strategic planning, portfolio management and product/program management. In fact, my various readings on Agile have provided lucid options for implementing Agile at various levels. The following sentence from a PMI training handbook may explain my bafflement (and the gist of what inspired this article): “The hardest part for technical professionals being Executives is to make decisions with incomplete data.” The emphases are not mine; they are the author’s. Is the PMI serving a niche for executives who also tend to be technical professionals? What then is their role on the management team? Decision making is frequently made with incomplete data; that is where Agile can help – to construct more realistic estimates for decision makers.
I was recently chatting with an Agilist who is a PMP (among other certifications) – and a very seasoned project manager – and also has a through understanding of Agile; he works primarily with Kanban and SAFe (Scaled Agile Framework). SAFe in fact does provide a framework for micro-to-macro scaling of Agile for project-portfolio-program management. But the PMI has deemed that SAFe inadequately meets this enterprise level need. I asked him what he thought of this claim and he laughed and said “It’s sour grapes; the PMI wishes it had gotten there first.” 

Lean v Bloated: Agile is about business value and – in line with Lean – about eliminating waste. The PMI is bloated with self-referencing jargon that features outdated constructs and is, I believe, incapable of seeing past that paradigm. Case in point – I recently read literature where the iron triangle, no longer relevant in an Agile world, transmuted into some sort of ‘iron hexagon’ with quality, risk and resources thrown in along with the traditional areas of scope, cost and schedule. Not only does that idea lack elegance but it is a poor attempt to theorise – and reactively – in the face of new facts. As someone who has engaged in reading both sets of doctrines, I see Agile as self-deprecatory and aiming for simplicity, even when dealing with complex software projects. 

Art v Science: Agile is simple to understand but can be problematic to implement because it is more of an art than science. I believe the same is true of project management; PMs who are skeptical of this are usually the ones who find solace in espousing the “hard math” and prescriptive methodology espoused by the PMI. Something like Estimation, which is a useful tool in Scrum, is something that throws many traditional PMs for a loop, especially the hard-core PMI advocates. For instance, the PMI sees Estimation as an exercise conducted with executives, not the delivery team. How would those estimates be meaningful, let alone something management could trust? The same holds for perceived percentile increases in productivity or ROI by using one methodology versus another. Every project, project team, approach and execution is different, which renders comparison and quantification a dubious exercise. The PMI touts statements like “Precision <> Accuracy”, harbouring the delusion that one can actually aspire to either metric in terms of project management methodologies. Agile understands the fallacy of attempting to be precise about something that is inherently inaccurate; the PMI believes that one can overcome the inexactitude of the estimation process with sufficient investment in precision.

I recently attended a one-day class on “Advanced Agile – Enterprise Practices” and it cemented my belief that you can either be Agile, or you can believe project management is a science.

Executive Management v Team Delivery: Typically, in Agile, the Product Owner provides a vision and the delivery team takes that vision and deconstructs that into themes and then user stories. The PMI has the executive team doing this deconstructing, taking into account the value of Minimum Marketable Features (MMF), which would be rather ludicrous unless they were all SMEs, since only technical experts would be able to speak at a detailed level as to the effort involved in creating MMFs. This is purportedly done under the aegis of Strategic Planning to create a Product Roadmap. Agile estimation is not a planning process for AOP (Annual Operating Plan); this would be a misapplication of a development tool. The PMI further talks about “spec’ing” out these themes, which is not the language or methodology of Agile and proves it is missing the point. This confusion or propensity to interchange executive teams with delivery teams is another hallmark of the PMI’s obtuseness when it comes Agile execution.  

Command & Control’ v Self-Directed: Traditional PM methodologies focus on controlling their projects to the nth level of detail. For example, they place great importance on a scheduling tool that can “scientifically” measure expected duration for a given set of tasks. This is predicated on a sort of ‘build it and they will come’ principle in that if we follow all the rules of traditional project management for scheduling and measuring earned value and so on, the project will be a success. This may in fact be true of certain types of projects – large engineering and defence projects, for example, where up-front planning helps map out complicated processes and dependencies. The PMI regards control as the Holy Grail of project management. But, control is often illusory. Working Agile gives more timely and accurate insight into project progress because the process embodies transparency. It is also predicated on the team “pulling” work rather than the project manager imposing scope, which makes it more sustainable and a more honest as well as dynamic reflection of the team’s capabilities.

Formalised v Spontaneous: Communication and planning in Agile projects are tailored to meet existing situational needs. Just in Time, Last Responsible Moment, Face-to-Face instead of document handoffs… all these are alien to the prescriptive nature of PMI philosophy. As I mentioned earlier, the PMI claims that every Agile framework is missing two critical elements: sophisticated scheduling tools and account cost management. I disagree on the need for the first and the lack of the second. In Scrum, for example, product backlog prioritisation is performed iteratively, and that is but one of the reasons that Agile makes monetary project investment more valuable and trackable.
Agile empowers the team; PMI methodology reassures executive management that the project is regulated to within an inch of its life. Control – or the illusion thereof – is critical.

People v Process: Agile invests in developing individuals. Agile coaches are trained to maximize potential in team members; the PMI has no articulated interest in fostering personal development in any of the project team. The main goal is achieving what the project set out to do, within time and budget. Becoming a servant leader and allowing the team to take front and centre is a major shift from the PMI viewpoint.
Fanciful though it sounds, Agile seems to play the role of David to PMI’s Goliath. Given that Agile approaches are becoming ubiquitous, this may not hold true for long. But it feels like the PMI is fighting a rearguard offensive, to stay relevant.

In Conclusion

blanace train tacks - jonathan pendleton - unsplashIs a meeting of the minds possible?
Symbiosis, not hierarchy: I believe a meeting of the minds is possible, that Agile and PMI can have a symbiotic relationship without the presumption of a hierarchy.  Some types of projects do lend themselves to a high degree of control and planning, and what the PMI offers provides a useful arsenal to a project manager in dealings with skittish management. In the end, the main goal is still to deliver value to business – does being a servant-leader render us any less useful? I don’t believe so. The PMI needs to acknowledge that Agile methodologies do a superior job at projects where requirements are changing; there is not much, if anything, that the PMI can contribute to the Agile body of knowledge. Rather than try to claim a stake in an area that has already been well-mined, the PMI would be better served – and better serve its adherents – by standing by the principles that work so well for specific kinds of endeavours. 

Book Club: The Go-Giver

PG Book club

 

 

 

 

 

Plaster Group’s consultants all got on the same page and received a copy of The Go-Giver, A Little Story About a Powerful Business Idea by Bob Burg and John David Mann. A quick read, this novel shares the lessons learned by the main character, Joe, as he engages with a massively successful (but mysterious) mentor. The mentor passes to Joe his “Five Laws of Stratospheric Success”… Continue reading “Book Club: The Go-Giver”