I’ve lived in my house for a long time and it’s time for a refresh. Over the last several months, I planned what needed significant investment and what only needed a cosmetic update. A couple of things were evident: new windows, for one. I was confident that the rest could be handled with some spackle and a new coat of paint, especially a pesky crack in the ceiling in my kitchen. Easy repair. It looked good, but shortly the crack appeared again. Maybe it was the spackle, or maybe I painted too soon. So, I bought different spackle and a nifty new spatula to try it again. A couple of weeks later, the same crack reappeared. In the meantime, I called my contractor and asked him to give me an estimate for new windows. He did and told me I could fix them for far less than I’d budgeted. I was thrilled. On his way out, I asked him about the crack in the ceiling. After poking it, he immediately went up to the bathroom that sat over the kitchen. When he returned, he held an old elbow pipe that had corroded. Climbing back up, he pushed a little harder on the crack and a small but steady stream of water flowed out. What I thought was a quick and easy fix turned into a significant repair. I lacked visibility into the real problem and it cost me more in the long run. We see this in organizations every day. They plan strategically, but execute in a “get it done” manner that may cost them a lot more than the value it brings.
CSC announced today that it is acquiring AppLabs, a US-based IV&V testing vendor. At first glance, it's a win, maybe a win for both sides. CSC states that one of the reasons that it acquired AppLabs is to augment its horizontal application strategy - due to AppLabs' presence in the US and UK (both vendors have firmly rooted practices in both markets) and to leverage AppLabs' testing strength in both custom and package applications. It's clearly a win for CSC:
This acquisition brings the larger vendor something new - a foot into the ISV market. AppLabs has had a pretty successful track record in testing software products. Historically, CSC's focus has been supporting internal IT for both private and public sectors.
AppLabs is one of the vendors that has been consistently successful in adapting both iterative and Agile practices to its test methodology. This allows it, if it can transfer AppLabs' approach into its current testing practices, to better poise itself to support testing continuous build and integration environments.
Gaining visibility into the big picture of an IT portfolio feels like one of the unsolvable challenges, and it’s not for lack of trying. Dashboards abound, and PPM tools are becoming more user friendly all the time, but do these tools really provide transparency into what’s really going on? Sometimes I think these tools provide MORE information than what you need, akin to telling you how to build the watch when all you want is the time. After reading Dave West’s “Why Kanban Matters,” I think more and more about how Kanban will provide project management offices with the information they need so that it can feed the portfolio more efficiently.
At a glance, the PMO knows where everything is in its cycle, what’s in the pipeline, and a brief status of what is important or in the need to know. Depending on the information that bubbles up in the brief status line, the PMO can determine where there may be resource constraints or where demand is driving the next steps . . . and it enables executives to get a visual of how demand is affecting current projects and supports the PMO’s need to communicate status without flooding dashboards with useless information. This can drive valuable conversations based on clear, concise information — it’s hard to miss what on tap and what is being delayed. It’s a process whose time has come.
Have you thought about leveraging Kanban above the project level? I’d love to hear your comments.
On July 27, 2010, Parallax Capital Partners announced that it was acquiring Daptiv, a SaaS PPM vendor. Forrester customers who are current Daptiv customers or are considering Daptiv as a PPM vendor should not be deterred. As a $20 million vendor, Daptiv provided a strong work group for project portfolio management, performing well at the departmental or divisional level, but had limited capabilities in areas that were attractive to enterprisewide implementations, including functionality (i.e., resource management and financial project management) and ability to scale development or support - a typical problem for smaller vendors. Prior to the acquisition, the company had started down the path toward enterprise viability, but the vendor was still seen as best suited to small to medium-sized standalone implementations.
Acquisition by capital investment firms can mean prepping a company for sale, but with Parallax operating Daptiv as a wholly owned subsidiary, Daptiv’s future looks much more positive. Having Parallax’s backing, the vendor will now be able to:
Increase R&D funding to further develop the connectors for ERP integration as well as extend connectors to other demand management or portfolio management tools.
Provide resource management functionality that supports forecasting and capacity management.
Increase support capabilities for larger, more complex implementations in order to compete at the enterprise level.
Extend its Daptiv platform to encompass more work-related data and reporting.
Provide increased financial modeling at the portfolio level and project actual capture for financial reporting.
Deltek’s announcement today of its intent to acquire Maconomy has the potential to vault the vendor’s position as a potential leader in the project-based solutions (PBS) space. For midmarket organizations that deliver projects as a crucial part of their revenue generation, this is a good move.
While the focuses of the products share slight overlaps, the products themselves target different functionality and different markets. Deltek has long been a major vendor in the AEC and government contractor markets, while Maconomy, a Denmark-based PBS vendor, focuses on the public relations/advertising, legal, publishing and accounting markets.
Few overlaps – in customers and in industries.
Opening doors to new regions – Deltek has limited exposure in EMEA, and Maconomy has had a very difficult time penetrating North America.
Mature product sets – Deltek isn’t acquiring an idea but a full blown product. This will allow them to quickly pursue new customers in expanding regions.
What’s going to be a challenge:
Create visibility in existing markets in new regions – The struggles to gain penetration in the new regions won’t get any easier for either vendor; however, the solutions’ strengths may gain them easier entry.
Integration – Deltek is still working through integration challenges with some of its earlier acquisitions (namely, Welcom) and now adds another platform into the mix. The positive here is that Maconomy is fully functional on its own, and we don’t expect there to be huge overlap, if any.
Sales integration – Opening new regions and new industries can be a tough sales training challenge. Expect a few bumps.
Recently, I’ve been getting more inquiries around risk based testing. In addition to agile test methods and test estimation, test teams turning their eyes to risk based testing is just another positive step in integrating quality through out the SDLC. Yes, I still see QA engineers as having to put their evangelist hats on to educate their developer brothers and sisters that quality is more than just testing (don’t get me wrong, consistent unit and integration testing is a beautiful thing), however, any time that business and technology partners can think about impact and dependencies in their approach to a solid, workable application elevates quality to the next level.
Keep asking those questions about risk based testing – and make sure that you’re covering all of the angles. Make sure that you’re covering:
I've been working quite closely with fellow analysts Dave West and Mary Gerush surrounding project estimation. Regardless if you're in the Agile world, testing is factored in (well, unit testing anyway), and if you're in the traditional camp, we've heard the same pain from a number of Forrester customers. No matter what methodology we use, there's not enough time to test. To combat that, testing organizations are attempting to build a livable, usable framework to provide them with information to battle for sufficient testing time.
A common inquiry request to Forrester is asking for benchmarks for quality. Testing groups are struggling to figure out how well they’re doing and if the processes they’re fighting for are making a difference.
As teams become more agile, or, add more agile like practices to traditional
development practices, I’m seeing increasing frustration on the part of test
managers. Rapid development cycles and scrutinized bottom lines are putting
more pressure on them to deliver comprehensive testing in tighter time
frames. More and more testing is being taken on by development teams, and while
that is a positive trend to be sure. More stringent testing performed by
development is a good thing, as a long time QA manager myself, I used to pray
for consistent unit and integration testing, but, ultimately, developers are not
trained to think in the same way that QA does. Development testing is meant to
ensure that the code, service, or integration performs the way it was conceived;
it doesn’t always cover the assurance that the business process is being met
and it doesn’t replace the end to end perspective that an organization needs to
ensure that the highest quality software is being delivered. Development testing
is faster, to be sure. End to end testing takes more time, but it’s necessary.
Test managers must do something to prevent testing being co-opted by development
at the expense of business value.