10 Things

10 questions non-techie managers should ask about IT projects

0Comments

more +

By Keith Faigin

February 28, 2012, 9:13 AM PST

Takeaway: Business managers may lack the tech knowledge to make sure a project is on the right track. Here's what they should be asking IT to improve the odds of project success.

If you are a non-techie responsible for a project that involves developing or enhancing software, it can be hard to ask the right questions. It is critical, though, to stay engaged in the software development process and to keep the communication flowing — this greatly improves the likelihood of a successful project. Below are 10 questions that non-technical project stakeholders should ask their techie counterparts.

1: What's the best way to communicate with the technical resources?

This is a question you can ask an IT manager. Maybe there is a business analyst or project manager from IT assigned to coordinate and communicate with your techies. But if there isn't, that task may fall to you. Some techies will be much better at understanding your "business needs" than others. Make sure that the requirements are written down and that you read them (even if they are boring!). After you read them, go over them with your BA, PM, or techie. Even just paraphrasing each requirement can help avoid costly communication failures.

2: Can you show me what you've got so far? (Ask repeatedly)

The sooner you can provide feedback to your IT counterparts, the less costly it will be to make important course corrections. Let's face it: It's difficult to conceptualize how something like a piece of software will work based on written requirements. It's only when you see it in action that you find all the things that weren't mentioned or were, worse yet, just assumed. Ask to see the latest work — even if it is incomplete — so you can provide feedback. Maybe you will be providing feedback on a login page or a search screen that doesn't do anything yet. It doesn't matter. Get the team used to regularly showing you progress. Also, it never hurts if you've got donuts or bagels when you come around.

3: Are you waiting on me for anything?

Some projects will have a full-time project manager who will be keeping careful track of open issues. If you don't have a resource supporting you like that, make sure you track open questions and issues carefully. It's always a good idea to ask the techies if they're still waiting for an answer from you on something you missed.

4: How will this be tested?

A well-managed software development team will create a test strategy near the start of the project. Understand what that strategy is and ask questions if it doesn't make sense to you.

5: When can I help with testing?

Make sure that you or your users play an integral role in testing. That role may be to help develop test cases or it may be to test, hands-on. Ideally, it is both. Be sure that representatives from the business side are playing an active role in testing. They will have a better intuitive understanding of what is "right" than full-time QA folks who need to rely on test-scripts.

6: How does this system or change affect our other systems?

In a company with lots of systems that interact with each other, it can be difficult — for business users and techies alike — to identify how a change will affect other systems. As a business stakeholder, you should dedicate some time to thinking through how the project affects other downstream processes. You should also have a focused discussion with your technical counterparts on where the new or modified system touches other systems. If your project affects other systems, make sure they're considered in the test strategy you asked about two questions ago.

7: What does the system do when something goes wrong?

Unfortunately, things will go wrong. All well-designed systems should be designed to handle errors as gracefully as possible. Ask this question to verify that your system is being designed this way. Answers like "I don't know" or "They will get some kind of exception message" aren't good. Good answers will include an explanation of how the user and support staff will be notified in a way that makes sense; how bad or incomplete data will be prevented from going into the system; and how the process can be restarted after the error.

8: Can you show me the audit trail?

Most business users assume that all computer systems keep great records of what everyone has done on the system and all the history of changes and transactions. In general, none of this happens unless the people who developed the system thought to add those features. If these features are important to you (and I have seldom seen a business system where audit trails weren't important), make sure that they are part of the requirements and ask for a demonstration.

9: What happens when you are done?

Many projects risk falling apart during the handoff from the technologists to the business. Make sure there is a clear plan for what happens when the programming and testing are done. You may be focusing on a training plan or customer communication strategy, but you need to make sure the technical team has a solid plan for moving the system into production and transitioning from development to operations. This should include establishing who supports the system going forward as well as mundane issues, such as making sure backups are in place. Also, you know there are going to be some changes needed after the first release. Make sure the technical resources are available for those inevitable adjustments.

10: What do you think?

There are plenty of techies who aren't afraid to speak their mind about any number of subjects (regardless of whether they have an informed opinion). However, there are also plenty who really understand what the business is trying to achieve but are reticent about expressing their ideas. Ask them their opinions — you may gain some valuable insights.

Good technologists — such as the ones on my team — will bring up these questions themselves. But it never hurts to make sure. Take the time to ask these questions and any others you can think of. Use the project as an opportunity to expand your horizons a little and learn about how these systems work and are built. More than anything else, stay engaged in the project from start to finish. This will help ensure that you can ask the 11th question: "Where should we celebrate the successful completion of the project?"